1
0
mirror of https://github.com/postgres/postgres.git synced 2025-11-12 05:01:15 +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

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

View File

@@ -331,17 +331,17 @@ of the xid fields is atomic, so assuming it for xmin as well is no extra
risk.
pg_clog and pg_subtrans
pg_xact and pg_subtrans
-----------------------
pg_clog and pg_subtrans are permanent (on-disk) storage of transaction related
pg_xact and pg_subtrans are permanent (on-disk) storage of transaction related
information. There is a limited number of pages of each kept in memory, so
in many cases there is no need to actually read from disk. However, if
there's a long running transaction or a backend sitting idle with an open
transaction, it may be necessary to be able to read and write this information
from disk. They also allow information to be permanent across server restarts.
pg_clog records the commit status for each transaction that has been assigned
pg_xact records the commit status for each transaction that has been assigned
an XID. A transaction can be in progress, committed, aborted, or
"sub-committed". This last state means that it's a subtransaction that's no
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
transaction tree, so we can skip looking at pg_subtrans unless we know the
cache has been overflowed. See storage/ipc/procarray.c for the gory details.
slru.c is the supporting mechanism for both pg_clog and pg_subtrans. It
slru.c is the supporting mechanism for both pg_xact and pg_subtrans. It
implements the LRU policy for in-memory buffer pages. The high-level routines
for pg_clog are implemented in transam.c, while the low-level functions are in
for pg_xact are implemented in transam.c, while the low-level functions are in
clog.c. pg_subtrans is contained completely in subtrans.c.

View File

@@ -450,7 +450,7 @@ CLOGShmemInit(void)
{
ClogCtl->PagePrecedes = CLOGPagePrecedes;
SimpleLruInit(ClogCtl, "clog", CLOGShmemBuffers(), CLOG_LSNS_PER_PAGE,
CLogControlLock, "pg_clog", LWTRANCHE_CLOG_BUFFERS);
CLogControlLock, "pg_xact", LWTRANCHE_CLOG_BUFFERS);
}
/*

View File

@@ -3,7 +3,7 @@
* commit_ts.c
* PostgreSQL commit timestamp manager
*
* This module is a pg_clog-like system that stores the commit timestamp
* This module is a pg_xact-like system that stores the commit timestamp
* for each transaction.
*
* XLOG interactions: this module generates an XLOG record whenever a new

View File

@@ -3,7 +3,7 @@
* multixact.c
* PostgreSQL multi-transaction-log manager
*
* The pg_multixact manager is a pg_clog-like manager that stores an array of
* The pg_multixact manager is a pg_xact-like manager that stores an array of
* MultiXactMember for each MultiXactId. It is a fundamental part of the
* shared-row-lock implementation. Each MultiXactMember is comprised of a
* TransactionId and a set of flag bits. The name is a bit historical:

View File

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

View File

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

View File

@@ -1379,7 +1379,7 @@ FinishPreparedTransaction(const char *gid, bool isCommit)
/*
* The order of operations here is critical: make the XLOG entry for
* commit or abort, then mark the transaction committed or aborted in
* pg_clog, then remove its PGPROC from the global ProcArray (which means
* pg_xact, then remove its PGPROC from the global ProcArray (which means
* TransactionIdIsInProgress will stop saying the prepared xact is in
* progress), then run the post-commit or post-abort callbacks. The
* callbacks will release the locks the transaction held.
@@ -2093,7 +2093,7 @@ RecordTransactionCommitPrepared(TransactionId xid,
/* Flush XLOG to disk */
XLogFlush(recptr);
/* Mark the transaction committed in pg_clog */
/* Mark the transaction committed in pg_xact */
TransactionIdCommitTree(xid, nchildren, children);
/* Checkpoint can proceed now */

View File

@@ -1208,8 +1208,8 @@ RecordTransactionCommit(void)
/*
* Mark ourselves as within our "commit critical section". This
* forces any concurrent checkpoint to wait until we've updated
* pg_clog. Without this, it is possible for the checkpoint to set
* REDO after the XLOG record but fail to flush the pg_clog update to
* pg_xact. Without this, it is possible for the checkpoint to set
* REDO after the XLOG record but fail to flush the pg_xact update to
* disk, leading to loss of the transaction commit if the system
* crashes a little later.
*
@@ -2035,7 +2035,7 @@ CommitTransaction(void)
if (!is_parallel_worker)
{
/*
* We need to mark our XIDs as committed in pg_clog. This is where we
* We need to mark our XIDs as committed in pg_xact. This is where we
* durably commit.
*/
latestXid = RecordTransactionCommit();
@@ -2545,7 +2545,7 @@ AbortTransaction(void)
AtAbort_Twophase();
/*
* Advertise the fact that we aborted in pg_clog (assuming that we got as
* Advertise the fact that we aborted in pg_xact (assuming that we got as
* far as assigning an XID to advertise). But if we're inside a parallel
* worker, skip this; the user backend must be the one to write the abort
* record.
@@ -4631,7 +4631,7 @@ AbortSubTransaction(void)
s->parent->subTransactionId);
AtSubAbort_Notify();
/* Advertise the fact that we aborted in pg_clog. */
/* Advertise the fact that we aborted in pg_xact. */
(void) RecordTransactionAbort(true);
/* Post-abort cleanup */
@@ -5375,7 +5375,7 @@ xact_redo_commit(xl_xact_parsed_commit *parsed,
if (standbyState == STANDBY_DISABLED)
{
/*
* Mark the transaction committed in pg_clog.
* Mark the transaction committed in pg_xact.
*/
TransactionIdCommitTree(xid, parsed->nsubxacts, parsed->subxacts);
}
@@ -5393,7 +5393,7 @@ xact_redo_commit(xl_xact_parsed_commit *parsed,
RecordKnownAssignedTransactionIds(max_xid);
/*
* Mark the transaction committed in pg_clog. We use async commit
* Mark the transaction committed in pg_xact. We use async commit
* protocol during recovery to provide information on database
* consistency for when users try to set hint bits. It is important
* 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)
if (standbyState == STANDBY_DISABLED)
{
/* Mark the transaction aborted in pg_clog, no need for async stuff */
/* Mark the transaction aborted in pg_xact, no need for async stuff */
TransactionIdAbortTree(xid, parsed->nsubxacts, parsed->subxacts);
}
else
@@ -5546,7 +5546,7 @@ xact_redo_abort(xl_xact_parsed_abort *parsed, TransactionId xid)
*/
RecordKnownAssignedTransactionIds(max_xid);
/* Mark the transaction aborted in pg_clog, no need for async stuff */
/* Mark the transaction aborted in pg_xact, no need for async stuff */
TransactionIdAbortTree(xid, parsed->nsubxacts, parsed->subxacts);
/*

View File

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