diff options
Diffstat (limited to 'src/backend/storage/ipc/procarray.c')
| -rw-r--r-- | src/backend/storage/ipc/procarray.c | 34 |
1 files changed, 17 insertions, 17 deletions
diff --git a/src/backend/storage/ipc/procarray.c b/src/backend/storage/ipc/procarray.c index 4743526ced9..a3b6037a099 100644 --- a/src/backend/storage/ipc/procarray.c +++ b/src/backend/storage/ipc/procarray.c @@ -19,11 +19,11 @@ * * During hot standby, we also keep a list of XIDs representing transactions * that are known to be running in the master (or more precisely, were running - * as of the current point in the WAL stream). This list is kept in the + * as of the current point in the WAL stream). This list is kept in the * KnownAssignedXids array, and is updated by watching the sequence of * arriving XIDs. This is necessary because if we leave those XIDs out of * snapshots taken for standby queries, then they will appear to be already - * complete, leading to MVCC failures. Note that in hot standby, the PGPROC + * complete, leading to MVCC failures. Note that in hot standby, the PGPROC * array represents standby processes, which by definition are not running * transactions that have XIDs. * @@ -261,7 +261,7 @@ ProcArrayAdd(PGPROC *proc) if (arrayP->numProcs >= arrayP->maxProcs) { /* - * Ooops, no room. (This really shouldn't happen, since there is a + * Ooops, no room. (This really shouldn't happen, since there is a * fixed supply of PGPROC structs too, and so we should have failed * earlier.) */ @@ -1054,9 +1054,9 @@ TransactionIdIsActive(TransactionId xid) * ignored. * * This is used by VACUUM to decide which deleted tuples must be preserved - * in a table. allDbs = TRUE is needed for shared relations, but allDbs = + * in a table. allDbs = TRUE is needed for shared relations, but allDbs = * FALSE is sufficient for non-shared relations, since only backends in my - * own database could ever see the tuples in them. Also, we can ignore + * own database could ever see the tuples in them. Also, we can ignore * concurrently running lazy VACUUMs because (a) they must be working on other * tables, and (b) they don't need to do snapshot-based lookups. * @@ -1321,7 +1321,7 @@ GetSnapshotData(Snapshot snapshot) /* * If the transaction has been assigned an xid < xmax we add it to - * the snapshot, and update xmin if necessary. There's no need to + * the snapshot, and update xmin if necessary. There's no need to * store XIDs >= xmax, since we'll treat them as running anyway. * We don't bother to examine their subxids either. * @@ -1346,7 +1346,7 @@ GetSnapshotData(Snapshot snapshot) * do that much work while holding the ProcArrayLock. * * The other backend can add more subxids concurrently, but cannot - * remove any. Hence it's important to fetch nxids just once. + * remove any. Hence it's important to fetch nxids just once. * Should be safe to use memcpy, though. (We needn't worry about * missing any xids added concurrently, because they must postdate * xmax.) @@ -1782,7 +1782,7 @@ BackendPidGetProc(int pid) * Only main transaction Ids are considered. This function is mainly * useful for determining what backend owns a lock. * - * Beware that not every xact has an XID assigned. However, as long as you + * Beware that not every xact has an XID assigned. However, as long as you * only call this using an XID found on disk, you're safe. */ int @@ -1842,7 +1842,7 @@ IsBackendPid(int pid) * some snapshot we have. Since we examine the procarray with only shared * lock, there are race conditions: a backend could set its xmin just after * we look. Indeed, on multiprocessors with weak memory ordering, the - * other backend could have set its xmin *before* we look. We know however + * other backend could have set its xmin *before* we look. We know however * that such a backend must have held shared ProcArrayLock overlapping our * own hold of ProcArrayLock, else we would see its xmin update. Therefore, * any snapshot the other backend is taking concurrently with our scan cannot @@ -2295,7 +2295,7 @@ CountOtherDBBackends(Oid databaseId, int *nbackends, int *nprepared) * XidCacheRemoveRunningXids * * Remove a bunch of TransactionIds from the list of known-running - * subtransactions for my backend. Both the specified xid and those in + * subtransactions for my backend. Both the specified xid and those in * the xids[] array (of length nxids) are removed from the subxids cache. * latestXid must be the latest XID among the group. */ @@ -2401,7 +2401,7 @@ DisplayXidCache(void) * treated as running by standby transactions, even though they are not in * the standby server's PGPROC array. * - * We record all XIDs that we know have been assigned. That includes all the + * We record all XIDs that we know have been assigned. That includes all the * XIDs seen in WAL records, plus all unobserved XIDs that we can deduce have * been assigned. We can deduce the existence of unobserved XIDs because we * know XIDs are assigned in sequence, with no gaps. The KnownAssignedXids @@ -2410,7 +2410,7 @@ DisplayXidCache(void) * * During hot standby we do not fret too much about the distinction between * top-level XIDs and subtransaction XIDs. We store both together in the - * KnownAssignedXids list. In backends, this is copied into snapshots in + * KnownAssignedXids list. In backends, this is copied into snapshots in * GetSnapshotData(), taking advantage of the fact that XidInMVCCSnapshot() * doesn't care about the distinction either. Subtransaction XIDs are * effectively treated as top-level XIDs and in the typical case pg_subtrans @@ -2623,14 +2623,14 @@ ExpireOldKnownAssignedTransactionIds(TransactionId xid) * must hold shared ProcArrayLock to examine the array. To remove XIDs from * the array, the startup process must hold ProcArrayLock exclusively, for * the usual transactional reasons (compare commit/abort of a transaction - * during normal running). Compressing unused entries out of the array + * during normal running). Compressing unused entries out of the array * likewise requires exclusive lock. To add XIDs to the array, we just insert * them into slots to the right of the head pointer and then advance the head * pointer. This wouldn't require any lock at all, except that on machines * with weak memory ordering we need to be careful that other processors * see the array element changes before they see the head pointer change. * We handle this by using a spinlock to protect reads and writes of the - * head/tail pointers. (We could dispense with the spinlock if we were to + * head/tail pointers. (We could dispense with the spinlock if we were to * create suitable memory access barrier primitives and use those instead.) * The spinlock must be taken to read or write the head/tail pointers unless * the caller holds ProcArrayLock exclusively. @@ -2727,7 +2727,7 @@ KnownAssignedXidsCompress(bool force) * If exclusive_lock is true then caller already holds ProcArrayLock in * exclusive mode, so we need no extra locking here. Else caller holds no * lock, so we need to be sure we maintain sufficient interlocks against - * concurrent readers. (Only the startup process ever calls this, so no need + * concurrent readers. (Only the startup process ever calls this, so no need * to worry about concurrent writers.) */ static void @@ -2773,7 +2773,7 @@ KnownAssignedXidsAdd(TransactionId from_xid, TransactionId to_xid, Assert(tail >= 0 && tail < pArray->maxKnownAssignedXids); /* - * Verify that insertions occur in TransactionId sequence. Note that even + * Verify that insertions occur in TransactionId sequence. Note that even * if the last existing element is marked invalid, it must still have a * correctly sequenced XID value. */ @@ -2876,7 +2876,7 @@ KnownAssignedXidsSearch(TransactionId xid, bool remove) } /* - * Standard binary search. Note we can ignore the KnownAssignedXidsValid + * Standard binary search. Note we can ignore the KnownAssignedXidsValid * array here, since even invalid entries will contain sorted XIDs. */ first = tail; |