Skip to content

Commit 88e66d1

Browse files
robertmhaasrobertmhaas
committed
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
1 parent bd9028b commit 88e66d1

28 files changed

+84
-73
lines changed

‎doc/src/sgml/backup.sgml

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

‎doc/src/sgml/catalogs.sgml

+2-2
Original file line numberDiff line numberDiff line change
@@ -1893,7 +1893,7 @@
18931893
All transaction IDs before this one have been replaced with a permanent
18941894
(<quote>frozen</>) transaction ID in this table. This is used to track
18951895
whether the table needs to be vacuumed in order to prevent transaction
1896-
ID wraparound or to allow <literal>pg_clog</> to be shrunk. Zero
1896+
ID wraparound or to allow <literal>pg_xact</> to be shrunk. Zero
18971897
(<symbol>InvalidTransactionId</symbol>) if the relation is not a table.
18981898
</entry>
18991899
</row>
@@ -2570,7 +2570,7 @@
25702570
All transaction IDs before this one have been replaced with a permanent
25712571
(<quote>frozen</>) transaction ID in this database. This is used to
25722572
track whether the database needs to be vacuumed in order to prevent
2573-
transaction ID wraparound or to allow <literal>pg_clog</> to be shrunk.
2573+
transaction ID wraparound or to allow <literal>pg_xact</> to be shrunk.
25742574
It is the minimum of the per-table
25752575
<structname>pg_class</>.<structfield>relfrozenxid</> values.
25762576
</entry>

‎doc/src/sgml/config.sgml

+1-1
Original file line numberDiff line numberDiff line change
@@ -6004,7 +6004,7 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
60046004

60056005
<para>
60066006
Vacuum also allows removal of old files from the
6007-
<filename>pg_clog</> subdirectory, which is why the default
6007+
<filename>pg_xact</> subdirectory, which is why the default
60086008
is a relatively low 200 million transactions.
60096009
This parameter can only be set at server start, but the setting
60106010
can be reduced for individual tables by

‎doc/src/sgml/func.sgml

+1-1
Original file line numberDiff line numberDiff line change
@@ -15616,7 +15616,7 @@ SELECT * FROM pg_ls_dir('.') WITH ORDINALITY AS t(ls,n);
1561615616
postmaster.pid | 9
1561715617
pg_ident.conf | 10
1561815618
global | 11
15619-
pg_clog | 12
15619+
pg_xact | 12
1562015620
pg_snapshots | 13
1562115621
pg_multixact | 14
1562215622
PG_VERSION | 15

‎doc/src/sgml/maintenance.sgml

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

544544
<para>

‎doc/src/sgml/ref/pg_resetwal.sgml

+2-2
Original file line numberDiff line numberDiff line change
@@ -256,12 +256,12 @@ PostgreSQL documentation
256256

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

‎doc/src/sgml/ref/pg_rewind.sgml

+1-1
Original file line numberDiff line numberDiff line change
@@ -229,7 +229,7 @@ PostgreSQL documentation
229229
</step>
230230
<step>
231231
<para>
232-
Copy all other files such as <filename>pg_clog</filename> and
232+
Copy all other files such as <filename>pg_xact</filename> and
233233
configuration files from the source cluster to the target cluster
234234
(everything except the relation files).
235235
</para>

‎doc/src/sgml/storage.sgml

+5-5
Original file line numberDiff line numberDiff line change
@@ -77,11 +77,6 @@ Item
7777
<entry>Subdirectory containing transaction commit timestamp data</entry>
7878
</row>
7979

80-
<row>
81-
<entry><filename>pg_clog</></entry>
82-
<entry>Subdirectory containing transaction commit status data</entry>
83-
</row>
84-
8580
<row>
8681
<entry><filename>pg_dynshmem</></entry>
8782
<entry>Subdirectory containing files used by the dynamic shared memory
@@ -151,6 +146,11 @@ Item
151146
<entry>Subdirectory containing WAL (Write Ahead Log) files</entry>
152147
</row>
153148

149+
<row>
150+
<entry><filename>pg_xact</></entry>
151+
<entry>Subdirectory containing transaction commit status data</entry>
152+
</row>
153+
154154
<row>
155155
<entry><filename>postgresql.auto.conf</></entry>
156156
<entry>A file used for storing configuration parameters that are set by

‎doc/src/sgml/wal.sgml

+1-1
Original file line numberDiff line numberDiff line change
@@ -201,7 +201,7 @@
201201
</listitem>
202202
<listitem>
203203
<para>
204-
Internal data structures such as <filename>pg_clog</filename>, <filename>pg_subtrans</filename>, <filename>pg_multixact</filename>,
204+
Internal data structures such as <filename>pg_xact</filename>, <filename>pg_subtrans</filename>, <filename>pg_multixact</filename>,
205205
<filename>pg_serial</filename>, <filename>pg_notify</filename>, <filename>pg_stat</filename>, <filename>pg_snapshots</filename> are not directly
206206
checksummed, nor are pages protected by full page writes. However, where
207207
such data structures are persistent, WAL records are written that allow

‎src/backend/access/heap/heapam.c

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

‎src/backend/access/transam/README

+5-5
Original file line numberDiff line numberDiff line change
@@ -331,17 +331,17 @@ of the xid fields is atomic, so assuming it for xmin as well is no extra
331331
risk.
332332

333333

334-
pg_clog and pg_subtrans
334+
pg_xact and pg_subtrans
335335
-----------------------
336336

337-
pg_clog and pg_subtrans are permanent (on-disk) storage of transaction related
337+
pg_xact and pg_subtrans are permanent (on-disk) storage of transaction related
338338
information. There is a limited number of pages of each kept in memory, so
339339
in many cases there is no need to actually read from disk. However, if
340340
there's a long running transaction or a backend sitting idle with an open
341341
transaction, it may be necessary to be able to read and write this information
342342
from disk. They also allow information to be permanent across server restarts.
343343

344-
pg_clog records the commit status for each transaction that has been assigned
344+
pg_xact records the commit status for each transaction that has been assigned
345345
an XID. A transaction can be in progress, committed, aborted, or
346346
"sub-committed". This last state means that it's a subtransaction that's no
347347
longer running, but its parent has not updated its state yet. It is not
@@ -381,9 +381,9 @@ each transaction we keep a "cache" of Xids that are known to be part of the
381381
transaction tree, so we can skip looking at pg_subtrans unless we know the
382382
cache has been overflowed. See storage/ipc/procarray.c for the gory details.
383383

384-
slru.c is the supporting mechanism for both pg_clog and pg_subtrans. It
384+
slru.c is the supporting mechanism for both pg_xact and pg_subtrans. It
385385
implements the LRU policy for in-memory buffer pages. The high-level routines
386-
for pg_clog are implemented in transam.c, while the low-level functions are in
386+
for pg_xact are implemented in transam.c, while the low-level functions are in
387387
clog.c. pg_subtrans is contained completely in subtrans.c.
388388

389389

‎src/backend/access/transam/clog.c

+1-1
Original file line numberDiff line numberDiff line change
@@ -450,7 +450,7 @@ CLOGShmemInit(void)
450450
{
451451
ClogCtl->PagePrecedes = CLOGPagePrecedes;
452452
SimpleLruInit(ClogCtl, "clog", CLOGShmemBuffers(), CLOG_LSNS_PER_PAGE,
453-
CLogControlLock, "pg_clog", LWTRANCHE_CLOG_BUFFERS);
453+
CLogControlLock, "pg_xact", LWTRANCHE_CLOG_BUFFERS);
454454
}
455455

456456
/*

‎src/backend/access/transam/commit_ts.c

+1-1
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@
33
* commit_ts.c
44
* PostgreSQL commit timestamp manager
55
*
6-
* This module is a pg_clog-like system that stores the commit timestamp
6+
* This module is a pg_xact-like system that stores the commit timestamp
77
* for each transaction.
88
*
99
* XLOG interactions: this module generates an XLOG record whenever a new

‎src/backend/access/transam/multixact.c

+1-1
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@
33
* multixact.c
44
* PostgreSQL multi-transaction-log manager
55
*
6-
* The pg_multixact manager is a pg_clog-like manager that stores an array of
6+
* The pg_multixact manager is a pg_xact-like manager that stores an array of
77
* MultiXactMember for each MultiXactId. It is a fundamental part of the
88
* shared-row-lock implementation. Each MultiXactMember is comprised of a
99
* TransactionId and a set of flag bits. The name is a bit historical:

‎src/backend/access/transam/subtrans.c

+2-3
Original file line numberDiff line numberDiff line change
@@ -3,15 +3,14 @@
33
* subtrans.c
44
* PostgreSQL subtransaction-log manager
55
*
6-
* The pg_subtrans manager is a pg_clog-like manager that stores the parent
6+
* The pg_subtrans manager is a pg_xact-like manager that stores the parent
77
* transaction Id for each transaction. It is a fundamental part of the
88
* nested transactions implementation. A main transaction has a parent
99
* of InvalidTransactionId, and each subtransaction has its immediate parent.
1010
* The tree can easily be walked from child to parent, but not in the
1111
* opposite direction.
1212
*
13-
* This code is based on clog.c, but the robustness requirements
14-
* are completely different from pg_clog, because we only need to remember
13+
* are completely different from pg_xact, because we only need to remember
1514
* pg_subtrans information for currently-open transactions. Thus, there is
1615
* no need to preserve data over a crash and restart.
1716
*

‎src/backend/access/transam/transam.c

+1-1
Original file line numberDiff line numberDiff line change
@@ -224,7 +224,7 @@ TransactionIdDidAbort(TransactionId transactionId)
224224
* True iff transaction associated with the identifier is currently
225225
* known to have either committed or aborted.
226226
*
227-
* This does NOT look into pg_clog but merely probes our local cache
227+
* This does NOT look into pg_xact but merely probes our local cache
228228
* (and so it's not named TransactionIdDidComplete, which would be the
229229
* appropriate name for a function that worked that way). The intended
230230
* use is just to short-circuit TransactionIdIsInProgress calls when doing

‎src/backend/access/transam/twophase.c

+2-2
Original file line numberDiff line numberDiff line change
@@ -1379,7 +1379,7 @@ FinishPreparedTransaction(const char *gid, bool isCommit)
13791379
/*
13801380
* The order of operations here is critical: make the XLOG entry for
13811381
* commit or abort, then mark the transaction committed or aborted in
1382-
* pg_clog, then remove its PGPROC from the global ProcArray (which means
1382+
* pg_xact, then remove its PGPROC from the global ProcArray (which means
13831383
* TransactionIdIsInProgress will stop saying the prepared xact is in
13841384
* progress), then run the post-commit or post-abort callbacks. The
13851385
* callbacks will release the locks the transaction held.
@@ -2093,7 +2093,7 @@ RecordTransactionCommitPrepared(TransactionId xid,
20932093
/* Flush XLOG to disk */
20942094
XLogFlush(recptr);
20952095

2096-
/* Mark the transaction committed in pg_clog */
2096+
/* Mark the transaction committed in pg_xact */
20972097
TransactionIdCommitTree(xid, nchildren, children);
20982098

20992099
/* Checkpoint can proceed now */

‎src/backend/access/transam/xact.c

+9-9
Original file line numberDiff line numberDiff line change
@@ -1208,8 +1208,8 @@ RecordTransactionCommit(void)
12081208
/*
12091209
* Mark ourselves as within our "commit critical section". This
12101210
* forces any concurrent checkpoint to wait until we've updated
1211-
* pg_clog. Without this, it is possible for the checkpoint to set
1212-
* REDO after the XLOG record but fail to flush the pg_clog update to
1211+
* pg_xact. Without this, it is possible for the checkpoint to set
1212+
* REDO after the XLOG record but fail to flush the pg_xact update to
12131213
* disk, leading to loss of the transaction commit if the system
12141214
* crashes a little later.
12151215
*
@@ -2035,7 +2035,7 @@ CommitTransaction(void)
20352035
if (!is_parallel_worker)
20362036
{
20372037
/*
2038-
* We need to mark our XIDs as committed in pg_clog. This is where we
2038+
* We need to mark our XIDs as committed in pg_xact. This is where we
20392039
* durably commit.
20402040
*/
20412041
latestXid = RecordTransactionCommit();
@@ -2545,7 +2545,7 @@ AbortTransaction(void)
25452545
AtAbort_Twophase();
25462546

25472547
/*
2548-
* Advertise the fact that we aborted in pg_clog (assuming that we got as
2548+
* Advertise the fact that we aborted in pg_xact (assuming that we got as
25492549
* far as assigning an XID to advertise). But if we're inside a parallel
25502550
* worker, skip this; the user backend must be the one to write the abort
25512551
* record.
@@ -4631,7 +4631,7 @@ AbortSubTransaction(void)
46314631
s->parent->subTransactionId);
46324632
AtSubAbort_Notify();
46334633

4634-
/* Advertise the fact that we aborted in pg_clog. */
4634+
/* Advertise the fact that we aborted in pg_xact. */
46354635
(void) RecordTransactionAbort(true);
46364636

46374637
/* Post-abort cleanup */
@@ -5375,7 +5375,7 @@ xact_redo_commit(xl_xact_parsed_commit *parsed,
53755375
if (standbyState == STANDBY_DISABLED)
53765376
{
53775377
/*
5378-
* Mark the transaction committed in pg_clog.
5378+
* Mark the transaction committed in pg_xact.
53795379
*/
53805380
TransactionIdCommitTree(xid, parsed->nsubxacts, parsed->subxacts);
53815381
}
@@ -5393,7 +5393,7 @@ xact_redo_commit(xl_xact_parsed_commit *parsed,
53935393
RecordKnownAssignedTransactionIds(max_xid);
53945394

53955395
/*
5396-
* Mark the transaction committed in pg_clog. We use async commit
5396+
* Mark the transaction committed in pg_xact. We use async commit
53975397
* protocol during recovery to provide information on database
53985398
* consistency for when users try to set hint bits. It is important
53995399
* that we do not set hint bits until the minRecoveryPoint is past
@@ -5530,7 +5530,7 @@ xact_redo_abort(xl_xact_parsed_abort *parsed, TransactionId xid)
55305530

55315531
if (standbyState == STANDBY_DISABLED)
55325532
{
5533-
/* Mark the transaction aborted in pg_clog, no need for async stuff */
5533+
/* Mark the transaction aborted in pg_xact, no need for async stuff */
55345534
TransactionIdAbortTree(xid, parsed->nsubxacts, parsed->subxacts);
55355535
}
55365536
else
@@ -5546,7 +5546,7 @@ xact_redo_abort(xl_xact_parsed_abort *parsed, TransactionId xid)
55465546
*/
55475547
RecordKnownAssignedTransactionIds(max_xid);
55485548

5549-
/* Mark the transaction aborted in pg_clog, no need for async stuff */
5549+
/* Mark the transaction aborted in pg_xact, no need for async stuff */
55505550
TransactionIdAbortTree(xid, parsed->nsubxacts, parsed->subxacts);
55515551

55525552
/*

‎src/backend/access/transam/xlog.c

+1-1
Original file line numberDiff line numberDiff line change
@@ -8710,7 +8710,7 @@ CreateCheckPoint(int flags)
87108710
* that are currently in commit critical sections. If an xact inserted
87118711
* its commit record into XLOG just before the REDO point, then a crash
87128712
* restart from the REDO point would not replay that record, which means
8713-
* that our flushing had better include the xact's update of pg_clog. So
8713+
* that our flushing had better include the xact's update of pg_xact. So
87148714
* we wait till he's out of his commit critical section before proceeding.
87158715
* See notes in RecordTransactionCommit().
87168716
*

‎src/backend/commands/vacuum.c

+5-5
Original file line numberDiff line numberDiff line change
@@ -357,7 +357,7 @@ vacuum(int options, RangeVar *relation, Oid relid, VacuumParams *params,
357357
if ((options & VACOPT_VACUUM) && !IsAutoVacuumWorkerProcess())
358358
{
359359
/*
360-
* Update pg_database.datfrozenxid, and truncate pg_clog if possible.
360+
* Update pg_database.datfrozenxid, and truncate pg_xact if possible.
361361
* (autovacuum.c does this for itself.)
362362
*/
363363
vac_update_datfrozenxid();
@@ -910,7 +910,7 @@ vac_update_relstats(Relation relation,
910910
* pg_class.relminmxid values.
911911
*
912912
* If we are able to advance either pg_database value, also try to
913-
* truncate pg_clog and pg_multixact.
913+
* truncate pg_xact and pg_multixact.
914914
*
915915
* We violate transaction semantics here by overwriting the database's
916916
* existing pg_database tuple with the new values. This is reasonably
@@ -1056,7 +1056,7 @@ vac_update_datfrozenxid(void)
10561056

10571057
/*
10581058
* If we were able to advance datfrozenxid or datminmxid, see if we can
1059-
* truncate pg_clog and/or pg_multixact. Also do it if the shared
1059+
* truncate pg_xact and/or pg_multixact. Also do it if the shared
10601060
* XID-wrap-limit info is stale, since this action will update that too.
10611061
*/
10621062
if (dirty || ForceTransactionIdLimitUpdate())
@@ -1069,7 +1069,7 @@ vac_update_datfrozenxid(void)
10691069
* vac_truncate_clog() -- attempt to truncate the commit log
10701070
*
10711071
* Scan pg_database to determine the system-wide oldest datfrozenxid,
1072-
* and use it to truncate the transaction commit log (pg_clog).
1072+
* and use it to truncate the transaction commit log (pg_xact).
10731073
* Also update the XID wrap limit info maintained by varsup.c.
10741074
* Likewise for datminmxid.
10751075
*
@@ -1116,7 +1116,7 @@ vac_truncate_clog(TransactionId frozenXID,
11161116
* of the interlock against copying a DB containing an active backend.
11171117
* Hence the new entry will not reduce the minimum. Also, if two VACUUMs
11181118
* concurrently modify the datfrozenxid's of different databases, the
1119-
* worst possible outcome is that pg_clog is not truncated as aggressively
1119+
* worst possible outcome is that pg_xact is not truncated as aggressively
11201120
* as it could be.
11211121
*/
11221122
relation = heap_open(DatabaseRelationId, AccessShareLock);

‎src/backend/postmaster/autovacuum.c

+1-1
Original file line numberDiff line numberDiff line change
@@ -2472,7 +2472,7 @@ do_autovacuum(void)
24722472
*/
24732473

24742474
/*
2475-
* Update pg_database.datfrozenxid, and truncate pg_clog if possible. We
2475+
* Update pg_database.datfrozenxid, and truncate pg_xact if possible. We
24762476
* only need to do this once, not after each table.
24772477
*
24782478
* Even if we didn't vacuum anything, it may still be important to do

‎src/backend/storage/buffer/README

+1-1
Original file line numberDiff line numberDiff line change
@@ -63,7 +63,7 @@ at about the same time would OR the same bits into the field, so there
6363
is little or no risk of conflicting update; what's more, if there did
6464
manage to be a conflict it would merely mean that one bit-update would
6565
be lost and need to be done again later. These four bits are only hints
66-
(they cache the results of transaction status lookups in pg_clog), so no
66+
(they cache the results of transaction status lookups in pg_xact), so no
6767
great harm is done if they get reset to zero by conflicting updates.
6868
Note, however, that a tuple is frozen by setting both HEAP_XMIN_INVALID
6969
and HEAP_XMIN_COMMITTED; this is a critical update and accordingly requires

0 commit comments

Comments
 (0)