1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00

Rename "pg_clog" directory to "pg_xact".

Names containing the letters "log" sometimes confuse users into
believing that only non-critical data is present.  It is hoped
this renaming will discourage ill-considered removals of transaction
status data.

Michael Paquier

Discussion: http://postgr.es/m/CA+Tgmoa9xFQyjRZupbdEFuwUerFTvC6HjZq1ud6GYragGDFFgA@mail.gmail.com
This commit is contained in:
Robert Haas
2017-03-17 09:46:58 -04:00
parent bd9028b824
commit 88e66d193f
28 changed files with 84 additions and 73 deletions

View File

@ -382,10 +382,10 @@ tar -cf backup.tar /usr/local/pgsql/data
directories. This will <emphasis>not</> work because the
information contained in these files is not usable without
the commit log files,
<filename>pg_clog/*</filename>, which contain the commit status of
<filename>pg_xact/*</filename>, which contain the commit status of
all transactions. A table file is only usable with this
information. Of course it is also impossible to restore only a
table and the associated <filename>pg_clog</filename> data
table and the associated <filename>pg_xact</filename> data
because that would render all other tables in the database
cluster useless. So file system backups only work for complete
backup and restoration of an entire database cluster.

View File

@ -1893,7 +1893,7 @@
All transaction IDs before this one have been replaced with a permanent
(<quote>frozen</>) transaction ID in this table. This is used to track
whether the table needs to be vacuumed in order to prevent transaction
ID wraparound or to allow <literal>pg_clog</> to be shrunk. Zero
ID wraparound or to allow <literal>pg_xact</> to be shrunk. Zero
(<symbol>InvalidTransactionId</symbol>) if the relation is not a table.
</entry>
</row>
@ -2570,7 +2570,7 @@
All transaction IDs before this one have been replaced with a permanent
(<quote>frozen</>) transaction ID in this database. This is used to
track whether the database needs to be vacuumed in order to prevent
transaction ID wraparound or to allow <literal>pg_clog</> to be shrunk.
transaction ID wraparound or to allow <literal>pg_xact</> to be shrunk.
It is the minimum of the per-table
<structname>pg_class</>.<structfield>relfrozenxid</> values.
</entry>

View File

@ -6004,7 +6004,7 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
<para>
Vacuum also allows removal of old files from the
<filename>pg_clog</> subdirectory, which is why the default
<filename>pg_xact</> subdirectory, which is why the default
is a relatively low 200 million transactions.
This parameter can only be set at server start, but the setting
can be reduced for individual tables by

View File

@ -15616,7 +15616,7 @@ SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS t(ls,n);
postmaster.pid | 9
pg_ident.conf | 10
global | 11
pg_clog | 12
pg_xact | 12
pg_snapshots | 13
pg_multixact | 14
PG_VERSION | 15

View File

@ -527,18 +527,18 @@
<para>
The sole disadvantage of increasing <varname>autovacuum_freeze_max_age</>
(and <varname>vacuum_freeze_table_age</> along with it)
is that the <filename>pg_clog</> subdirectory of the database cluster
is that the <filename>pg_xact</> subdirectory of the database cluster
will take more space, because it must store the commit status of all
transactions back to the <varname>autovacuum_freeze_max_age</> horizon.
The commit status uses two bits per transaction, so if
<varname>autovacuum_freeze_max_age</> is set to its maximum allowed
value of two billion, <filename>pg_clog</> can be expected to
value of two billion, <filename>pg_xact</> can be expected to
grow to about half a gigabyte. If this is trivial compared to your
total database size, setting <varname>autovacuum_freeze_max_age</> to
its maximum allowed value is recommended. Otherwise, set it depending
on what you are willing to allow for <filename>pg_clog</> storage.
on what you are willing to allow for <filename>pg_xact</> storage.
(The default, 200 million transactions, translates to about 50MB of
<filename>pg_clog</> storage.)
<filename>pg_xact</> storage.)
</para>
<para>

View File

@ -256,12 +256,12 @@ PostgreSQL documentation
<para>
A safe value can be determined by looking for the numerically largest
file name in the directory <filename>pg_clog</> under the data directory,
file name in the directory <filename>pg_xact</> under the data directory,
adding one,
and then multiplying by 1048576 (0x100000). Note that the file names are in
hexadecimal. It is usually easiest to specify the option value in
hexadecimal too. For example, if <filename>0011</> is the largest entry
in <filename>pg_clog</>, <literal>-x 0x1200000</> will work (five
in <filename>pg_xact</>, <literal>-x 0x1200000</> will work (five
trailing zeroes provide the proper multiplier).
</para>
</listitem>

View File

@ -229,7 +229,7 @@ PostgreSQL documentation
</step>
<step>
<para>
Copy all other files such as <filename>pg_clog</filename> and
Copy all other files such as <filename>pg_xact</filename> and
configuration files from the source cluster to the target cluster
(everything except the relation files).
</para>

View File

@ -77,11 +77,6 @@ Item
<entry>Subdirectory containing transaction commit timestamp data</entry>
</row>
<row>
<entry><filename>pg_clog</></entry>
<entry>Subdirectory containing transaction commit status data</entry>
</row>
<row>
<entry><filename>pg_dynshmem</></entry>
<entry>Subdirectory containing files used by the dynamic shared memory
@ -151,6 +146,11 @@ Item
<entry>Subdirectory containing WAL (Write Ahead Log) files</entry>
</row>
<row>
<entry><filename>pg_xact</></entry>
<entry>Subdirectory containing transaction commit status data</entry>
</row>
<row>
<entry><filename>postgresql.auto.conf</></entry>
<entry>A file used for storing configuration parameters that are set by

View File

@ -201,7 +201,7 @@
</listitem>
<listitem>
<para>
Internal data structures such as <filename>pg_clog</filename>, <filename>pg_subtrans</filename>, <filename>pg_multixact</filename>,
Internal data structures such as <filename>pg_xact</filename>, <filename>pg_subtrans</filename>, <filename>pg_multixact</filename>,
<filename>pg_serial</filename>, <filename>pg_notify</filename>, <filename>pg_stat</filename>, <filename>pg_snapshots</filename> are not directly
checksummed, nor are pages protected by full page writes. However, where
such data structures are persistent, WAL records are written that allow