diff options
Diffstat (limited to 'src/backend/utils/time')
| -rw-r--r-- | src/backend/utils/time/combocid.c | 2 | ||||
| -rw-r--r-- | src/backend/utils/time/snapmgr.c | 10 | ||||
| -rw-r--r-- | src/backend/utils/time/tqual.c | 14 |
3 files changed, 13 insertions, 13 deletions
diff --git a/src/backend/utils/time/combocid.c b/src/backend/utils/time/combocid.c index d9b37b2ba3f..772ae17ba43 100644 --- a/src/backend/utils/time/combocid.c +++ b/src/backend/utils/time/combocid.c @@ -15,7 +15,7 @@ * this module. * * To allow reusing existing combo cids, we also keep a hash table that - * maps cmin,cmax pairs to combo cids. This keeps the data structure size + * maps cmin,cmax pairs to combo cids. This keeps the data structure size * reasonable in most cases, since the number of unique pairs used by any * one transaction is likely to be small. * diff --git a/src/backend/utils/time/snapmgr.c b/src/backend/utils/time/snapmgr.c index 5917b014fdc..2ce477f3991 100644 --- a/src/backend/utils/time/snapmgr.c +++ b/src/backend/utils/time/snapmgr.c @@ -8,9 +8,9 @@ * (tracked by separate refcounts on each snapshot), its memory can be freed. * * These arrangements let us reset MyProc->xmin when there are no snapshots - * referenced by this transaction. (One possible improvement would be to be + * referenced by this transaction. (One possible improvement would be to be * able to advance Xmin when the snapshot with the earliest Xmin is no longer - * referenced. That's a bit harder though, it requires more locking, and + * referenced. That's a bit harder though, it requires more locking, and * anyway it should be rather uncommon to keep snapshots referenced for too * long.) * @@ -41,7 +41,7 @@ * CurrentSnapshot points to the only snapshot taken in transaction-snapshot * mode, and to the latest one taken in a read-committed transaction. * SecondarySnapshot is a snapshot that's always up-to-date as of the current - * instant, even in transaction-snapshot mode. It should only be used for + * instant, even in transaction-snapshot mode. It should only be used for * special-purpose code (say, RI checking.) * * These SnapshotData structs are static to simplify memory allocation @@ -60,7 +60,7 @@ static Snapshot SecondarySnapshot = NULL; * mode, we don't want it to say that BootstrapTransactionId is in progress. * * RecentGlobalXmin is initialized to InvalidTransactionId, to ensure that no - * one tries to use a stale value. Readers should ensure that it has been set + * one tries to use a stale value. Readers should ensure that it has been set * to something else before using it. */ TransactionId TransactionXmin = FirstNormalTransactionId; @@ -270,7 +270,7 @@ FreeSnapshot(Snapshot snapshot) * * If the passed snapshot is a statically-allocated one, or it is possibly * subject to a future command counter update, create a new long-lived copy - * with active refcount=1. Otherwise, only increment the refcount. + * with active refcount=1. Otherwise, only increment the refcount. */ void PushActiveSnapshot(Snapshot snap) diff --git a/src/backend/utils/time/tqual.c b/src/backend/utils/time/tqual.c index b396e7ecf78..d7cb7a4a9c5 100644 --- a/src/backend/utils/time/tqual.c +++ b/src/backend/utils/time/tqual.c @@ -20,7 +20,7 @@ * TransactionIdDidCommit will both return true. If we check only * TransactionIdDidCommit, we could consider a tuple committed when a * later GetSnapshotData call will still think the originating transaction - * is in progress, which leads to application-level inconsistency. The + * is in progress, which leads to application-level inconsistency. The * upshot is that we gotta check TransactionIdIsInProgress first in all * code paths, except for a few cases where we are looking at * subtransactions of our own main transaction and so there can't be any @@ -87,13 +87,13 @@ static bool XidInMVCCSnapshot(TransactionId xid, Snapshot snapshot); * buffer, so we can't use the LSN to interlock this; we have to just refrain * from setting the hint bit until some future re-examination of the tuple. * - * We can always set hint bits when marking a transaction aborted. (Some + * We can always set hint bits when marking a transaction aborted. (Some * code in heapam.c relies on that!) * * Also, if we are cleaning up HEAP_MOVED_IN or HEAP_MOVED_OFF entries, then * we can always set the hint bits, since pre-9.0 VACUUM FULL always used * synchronous commits and didn't move tuples that weren't previously - * hinted. (This is not known by this subroutine, but is applied by its + * hinted. (This is not known by this subroutine, but is applied by its * callers.) Note: old-style VACUUM FULL is gone, but we have to keep this * module's support for MOVED_OFF/MOVED_IN flag bits for as long as we * support in-place update from pre-9.0 databases. @@ -490,7 +490,7 @@ HeapTupleSatisfiesAny(HeapTupleHeader tuple, Snapshot snapshot, Buffer buffer) * This is a simplified version that only checks for VACUUM moving conditions. * It's appropriate for TOAST usage because TOAST really doesn't want to do * its own time qual checks; if you can see the main table row that contains - * a TOAST reference, you should be able to see the TOASTed value. However, + * a TOAST reference, you should be able to see the TOASTed value. However, * vacuuming a TOAST table is independent of the main table, and in case such * a vacuum fails partway through, we'd better do this much checking. * @@ -1060,7 +1060,7 @@ HeapTupleSatisfiesMVCC(HeapTupleHeader tuple, Snapshot snapshot, * we mainly want to know is if a tuple is potentially visible to *any* * running transaction. If so, it can't be removed yet by VACUUM. * - * OldestXmin is a cutoff XID (obtained from GetOldestXmin()). Tuples + * OldestXmin is a cutoff XID (obtained from GetOldestXmin()). Tuples * deleted by XIDs >= OldestXmin are deemed "recently dead"; they might * still be visible to some open transaction, so we can't remove them, * even if we see that the deleting transaction has committed. @@ -1146,7 +1146,7 @@ HeapTupleSatisfiesVacuum(HeapTupleHeader tuple, TransactionId OldestXmin, } /* - * Okay, the inserter committed, so it was good at some point. Now what + * Okay, the inserter committed, so it was good at some point. Now what * about the deleting transaction? */ if (tuple->t_infomask & HEAP_XMAX_INVALID) @@ -1245,7 +1245,7 @@ XidInMVCCSnapshot(TransactionId xid, Snapshot snapshot) /* * Make a quick range check to eliminate most XIDs without looking at the - * xip arrays. Note that this is OK even if we convert a subxact XID to + * xip arrays. Note that this is OK even if we convert a subxact XID to * its parent below, because a subxact with XID < xmin has surely also got * a parent with XID < xmin, while one with XID >= xmax must belong to a * parent that was not yet committed at the time of this snapshot. |