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

Author: robertmhaas

doc/src/sgml/backup.sgml

@@ -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.

doc/src/sgml/catalogs.sgml

@@ -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>

doc/src/sgml/config.sgml

@@ -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

doc/src/sgml/func.sgml

@@ -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

doc/src/sgml/maintenance.sgml

@@ -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>

doc/src/sgml/ref/pg_resetwal.sgml

@@ -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>

doc/src/sgml/ref/pg_rewind.sgml

@@ -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>

doc/src/sgml/storage.sgml

@@ -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

doc/src/sgml/wal.sgml

@@ -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

src/backend/access/heap/heapam.c

@@ -6790,8 +6790,8 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple, TransactionId cutoff_xid,
  * Note: it might seem we could make the changes without exclusive lock, since
  * TransactionId read/write is assumed atomic anyway.  However there is a race
  * condition: someone who just fetched an old XID that we overwrite here could
- * conceivably not finish checking the XID against pg_clog before we finish
- * the VACUUM and perhaps truncate off the part of pg_clog he needs.  Getting
+ * conceivably not finish checking the XID against pg_xact before we finish
+ * the VACUUM and perhaps truncate off the part of pg_xact he needs.  Getting
  * exclusive lock ensures no other backend is in process of checking the
  * tuple status.  Also, getting exclusive lock makes it safe to adjust the
  * infomask bits.