database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-25 12:03:53 +03:00
Code Activity

Initial pgindent and pgperltidy run for v14.

Browse Source 
Also "make reformat-dat-files".

The only change worthy of note is that pgindent messed up the formatting
of launcher.c's struct LogicalRepWorkerId, which led me to notice that
that struct wasn't used at all anymore, so I just took it out.
This commit is contained in:
Tom Lane
2021-05-12 13:14:10 -04:00
parent e6ccd1ce16
commit def5b065ff
230 changed files with 2408 additions and 2125 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
src/backend/access/transam/varsup.c
View File

@@ -179,10 +179,10 @@ GetNewTransactionId(bool isSubXact)
ExtendSUBTRANS(xid);
/*
* Now advance the nextXid counter. This must not happen until after
* we have successfully completed ExtendCLOG() --- if that routine fails,
* we want the next incoming transaction to try it again. We cannot
* assign more XIDs until there is CLOG space for them.
* Now advance the nextXid counter. This must not happen until after we
* have successfully completed ExtendCLOG() --- if that routine fails, we
* want the next incoming transaction to try it again. We cannot assign
* more XIDs until there is CLOG space for them.
*/
FullTransactionIdAdvance(&ShmemVariableCache->nextXid);
@@ -192,8 +192,8 @@ GetNewTransactionId(bool isSubXact)
* latestCompletedXid is present in the ProcArray, which is essential for
* correct OldestXmin tracking; see src/backend/access/transam/README.
*
* Note that readers of ProcGlobal->xids/PGPROC->xid should be careful
* to fetch the value for each proc only once, rather than assume they can
* Note that readers of ProcGlobal->xids/PGPROC->xid should be careful to
* fetch the value for each proc only once, rather than assume they can
* read a value multiple times and get the same answer each time. Note we
* are assuming that TransactionId and int fetch/store are atomic.
*
@@ -281,9 +281,9 @@ AdvanceNextFullTransactionIdPastXid(TransactionId xid)
uint32 epoch;
/*
* It is safe to read nextXid without a lock, because this is only
* called from the startup process or single-process mode, meaning that no
* other process can modify it.
* It is safe to read nextXid without a lock, because this is only called
* from the startup process or single-process mode, meaning that no other
* process can modify it.
*/
Assert(AmStartupProcess() || !IsUnderPostmaster);
@@ -426,7 +426,7 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
/* Log the info */
ereport(DEBUG1,
(errmsg_internal("transaction ID wrap limit is %u, limited by database with OID %u",
xidWrapLimit, oldest_datoid)));
xidWrapLimit, oldest_datoid)));
/*
* If past the autovacuum force point, immediately signal an autovac
@@ -617,8 +617,8 @@ AssertTransactionIdInAllowableRange(TransactionId xid)
* We can't acquire XidGenLock, as this may be called with XidGenLock
* already held (or with other locks that don't allow XidGenLock to be
* nested). That's ok for our purposes though, since we already rely on
* 32bit reads to be atomic. While nextXid is 64 bit, we only look at
* the lower 32bit, so a skewed read doesn't hurt.
* 32bit reads to be atomic. While nextXid is 64 bit, we only look at the
* lower 32bit, so a skewed read doesn't hurt.
*
* There's no increased danger of falling outside [oldest, next] by
* accessing them without a lock. xid needs to have been created with