aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/xid8funcs.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-05-15 14:28:19 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-05-15 14:28:25 -0400
commit5da14938f7bfb96b648ee3c47e7ea2afca5bcc4a (patch)
treea637e548f3a39f0ebaef513f870964eb5dcecec9 /src/backend/utils/adt/xid8funcs.c
parent756abe2bc7608b38c579c510eb66f2bd80d10785 (diff)
downloadpostgresql-5da14938f7bfb96b648ee3c47e7ea2afca5bcc4a.tar.gz
postgresql-5da14938f7bfb96b648ee3c47e7ea2afca5bcc4a.zip
Rename SLRU structures and associated LWLocks.
Originally, the names assigned to SLRUs had no purpose other than being shmem lookup keys, so not a lot of thought went into them. As of v13, though, we're exposing them in the pg_stat_slru view and the pg_stat_reset_slru function, so it seems advisable to take a bit more care. Rename them to names based on the associated on-disk storage directories (which fortunately we *did* think about, to some extent; since those are also visible to DBAs, consistency seems like a good thing). Also rename the associated LWLocks, since those names are likewise user-exposed now as wait event names. For the most part I only touched symbols used in the respective modules' SimpleLruInit() calls, not the names of other related objects. This renaming could have been taken further, and maybe someday we will do so. But for now it seems undesirable to change the names of any globally visible functions or structs, so some inconsistency is unavoidable. (But I *did* terminate "oldserxid" with prejudice, as I found that name both unreadable and not descriptive of the SLRU's contents.) Table 27.12 needs re-alphabetization now, but I'll leave that till after the other LWLock renamings I have in mind. Discussion: https://postgr.es/m/28683.1589405363@sss.pgh.pa.us
Diffstat (limited to 'src/backend/utils/adt/xid8funcs.c')
-rw-r--r--src/backend/utils/adt/xid8funcs.c10
1 files changed, 5 insertions, 5 deletions
diff --git a/src/backend/utils/adt/xid8funcs.c b/src/backend/utils/adt/xid8funcs.c
index 616f187ad42..c4401f4adf7 100644
--- a/src/backend/utils/adt/xid8funcs.c
+++ b/src/backend/utils/adt/xid8funcs.c
@@ -82,7 +82,7 @@ typedef struct
* to the low 32 bits of the transaction ID (i.e. the actual XID, without the
* epoch).
*
- * The caller must hold CLogTruncationLock since it's dealing with arbitrary
+ * The caller must hold XactTruncationLock since it's dealing with arbitrary
* XIDs, and must continue to hold it until it's done with any clog lookups
* relating to those XIDs.
*/
@@ -118,13 +118,13 @@ TransactionIdInRecentPast(FullTransactionId fxid, TransactionId *extracted_xid)
U64FromFullTransactionId(fxid)))));
/*
- * ShmemVariableCache->oldestClogXid is protected by CLogTruncationLock,
+ * ShmemVariableCache->oldestClogXid is protected by XactTruncationLock,
* but we don't acquire that lock here. Instead, we require the caller to
* acquire it, because the caller is presumably going to look up the
* returned XID. If we took and released the lock within this function, a
* CLOG truncation could occur before the caller finished with the XID.
*/
- Assert(LWLockHeldByMe(CLogTruncationLock));
+ Assert(LWLockHeldByMe(XactTruncationLock));
/*
* If the transaction ID has wrapped around, it's definitely too old to
@@ -672,7 +672,7 @@ pg_xact_status(PG_FUNCTION_ARGS)
* We must protect against concurrent truncation of clog entries to avoid
* an I/O error on SLRU lookup.
*/
- LWLockAcquire(CLogTruncationLock, LW_SHARED);
+ LWLockAcquire(XactTruncationLock, LW_SHARED);
if (TransactionIdInRecentPast(fxid, &xid))
{
Assert(TransactionIdIsValid(xid));
@@ -706,7 +706,7 @@ pg_xact_status(PG_FUNCTION_ARGS)
{
status = NULL;
}
- LWLockRelease(CLogTruncationLock);
+ LWLockRelease(XactTruncationLock);
if (status == NULL)
PG_RETURN_NULL();