diff options
Diffstat (limited to 'src/backend/storage/lmgr/lock.c')
| -rw-r--r-- | src/backend/storage/lmgr/lock.c | 40 |
1 files changed, 20 insertions, 20 deletions
diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c index 676b3a49382..4327986a20c 100644 --- a/src/backend/storage/lmgr/lock.c +++ b/src/backend/storage/lmgr/lock.c @@ -187,7 +187,7 @@ static int FastPathLocalUseCount = 0; /* * The fast-path lock mechanism is concerned only with relation locks on - * unshared relations by backends bound to a database. The fast-path + * unshared relations by backends bound to a database. The fast-path * mechanism exists mostly to accelerate acquisition and release of locks * that rarely conflict. Because ShareUpdateExclusiveLock is * self-conflicting, it can't use the fast-path mechanism; but it also does @@ -914,7 +914,7 @@ LockAcquireExtended(const LOCKTAG *locktag, /* * If lock requested conflicts with locks requested by waiters, must join - * wait queue. Otherwise, check for conflict with already-held locks. + * wait queue. Otherwise, check for conflict with already-held locks. * (That's last because most complex check.) */ if (lockMethodTable->conflictTab[lockmode] & lock->waitMask) @@ -995,7 +995,7 @@ LockAcquireExtended(const LOCKTAG *locktag, /* * NOTE: do not do any material change of state between here and - * return. All required changes in locktable state must have been + * return. All required changes in locktable state must have been * done when the lock was granted to us --- see notes in WaitOnLock. */ @@ -1032,7 +1032,7 @@ LockAcquireExtended(const LOCKTAG *locktag, { /* * Decode the locktag back to the original values, to avoid sending - * lots of empty bytes with every message. See lock.h to check how a + * lots of empty bytes with every message. See lock.h to check how a * locktag is defined for LOCKTAG_RELATION */ LogAccessExclusiveLock(locktag->locktag_field1, @@ -1290,7 +1290,7 @@ LockCheckConflicts(LockMethod lockMethodTable, } /* - * Rats. Something conflicts. But it could still be my own lock. We have + * Rats. Something conflicts. But it could still be my own lock. We have * to construct a conflict mask that does not reflect our own locks, but * only lock types held by other processes. */ @@ -1382,7 +1382,7 @@ UnGrantLock(LOCK *lock, LOCKMODE lockmode, /* * We need only run ProcLockWakeup if the released lock conflicts with at - * least one of the lock types requested by waiter(s). Otherwise whatever + * least one of the lock types requested by waiter(s). Otherwise whatever * conflict made them wait must still exist. NOTE: before MVCC, we could * skip wakeup if lock->granted[lockmode] was still positive. But that's * not true anymore, because the remaining granted locks might belong to @@ -1402,7 +1402,7 @@ UnGrantLock(LOCK *lock, LOCKMODE lockmode, } /* - * CleanUpLock -- clean up after releasing a lock. We garbage-collect the + * CleanUpLock -- clean up after releasing a lock. We garbage-collect the * proclock and lock objects if possible, and call ProcLockWakeup if there * are remaining requests and the caller says it's OK. (Normally, this * should be called after UnGrantLock, and wakeupNeeded is the result from @@ -1824,7 +1824,7 @@ LockRelease(const LOCKTAG *locktag, LOCKMODE lockmode, bool sessionLock) } /* - * Decrease the total local count. If we're still holding the lock, we're + * Decrease the total local count. If we're still holding the lock, we're * done. */ locallock->nLocks--; @@ -1956,7 +1956,7 @@ LockReleaseAll(LOCKMETHODID lockmethodid, bool allLocks) #endif /* - * Get rid of our fast-path VXID lock, if appropriate. Note that this is + * Get rid of our fast-path VXID lock, if appropriate. Note that this is * the only way that the lock we hold on our own VXID can ever get * released: it is always and only released when a toplevel transaction * ends. @@ -2043,7 +2043,7 @@ LockReleaseAll(LOCKMETHODID lockmethodid, bool allLocks) * fast-path data structures, we must acquire it before attempting * to release the lock via the fast-path. We will continue to * hold the LWLock until we're done scanning the locallock table, - * unless we hit a transferred fast-path lock. (XXX is this + * unless we hit a transferred fast-path lock. (XXX is this * really such a good idea? There could be a lot of entries ...) */ if (!have_fast_path_lwlock) @@ -2062,7 +2062,7 @@ LockReleaseAll(LOCKMETHODID lockmethodid, bool allLocks) /* * Our lock, originally taken via the fast path, has been - * transferred to the main lock table. That's going to require + * transferred to the main lock table. That's going to require * some extra work, so release our fast-path lock before starting. */ LWLockRelease(MyProc->backendLock); @@ -2071,7 +2071,7 @@ LockReleaseAll(LOCKMETHODID lockmethodid, bool allLocks) /* * Now dump the lock. We haven't got a pointer to the LOCK or * PROCLOCK in this case, so we have to handle this a bit - * differently than a normal lock release. Unfortunately, this + * differently than a normal lock release. Unfortunately, this * requires an extra LWLock acquire-and-release cycle on the * partitionLock, but hopefully it shouldn't happen often. */ @@ -2504,9 +2504,9 @@ FastPathTransferRelationLocks(LockMethod lockMethodTable, const LOCKTAG *locktag * acquiring proc->backendLock. In particular, it's certainly safe to * assume that if the target backend holds any fast-path locks, it * must have performed a memory-fencing operation (in particular, an - * LWLock acquisition) since setting proc->databaseId. However, it's + * LWLock acquisition) since setting proc->databaseId. However, it's * less clear that our backend is certain to have performed a memory - * fencing operation since the other backend set proc->databaseId. So + * fencing operation since the other backend set proc->databaseId. So * for now, we test it after acquiring the LWLock just to be safe. */ if (proc->databaseId != locktag->locktag_field1) @@ -3020,7 +3020,7 @@ AtPrepare_Locks(void) continue; /* - * If we have both session- and transaction-level locks, fail. This + * If we have both session- and transaction-level locks, fail. This * should never happen with regular locks, since we only take those at * session level in some special operations like VACUUM. It's * possible to hit this with advisory locks, though. @@ -3029,7 +3029,7 @@ AtPrepare_Locks(void) * the transactional hold to the prepared xact. However, that would * require two PROCLOCK objects, and we cannot be sure that another * PROCLOCK will be available when it comes time for PostPrepare_Locks - * to do the deed. So for now, we error out while we can still do so + * to do the deed. So for now, we error out while we can still do so * safely. */ if (haveSessionLock) @@ -3216,7 +3216,7 @@ PostPrepare_Locks(TransactionId xid) /* * We cannot simply modify proclock->tag.myProc to reassign * ownership of the lock, because that's part of the hash key and - * the proclock would then be in the wrong hash chain. Instead + * the proclock would then be in the wrong hash chain. Instead * use hash_update_hash_key. (We used to create a new hash entry, * but that risks out-of-memory failure if other processes are * busy making proclocks too.) We must unlink the proclock from @@ -3316,7 +3316,7 @@ GetLockStatusData(void) /* * First, we iterate through the per-backend fast-path arrays, locking - * them one at a time. This might produce an inconsistent picture of the + * them one at a time. This might produce an inconsistent picture of the * system state, but taking all of those LWLocks at the same time seems * impractical (in particular, note MAX_SIMUL_LWLOCKS). It shouldn't * matter too much, because none of these locks can be involved in lock @@ -3395,7 +3395,7 @@ GetLockStatusData(void) * will be self-consistent. * * Since this is a read-only operation, we take shared instead of - * exclusive lock. There's not a whole lot of point to this, because all + * exclusive lock. There's not a whole lot of point to this, because all * the normal operations require exclusive lock, but it doesn't hurt * anything either. It will at least allow two backends to do * GetLockStatusData in parallel. @@ -3914,7 +3914,7 @@ lock_twophase_postabort(TransactionId xid, uint16 info, * as MyProc->lxid, you might wonder if we really need both. The * difference is that MyProc->lxid is set and cleared unlocked, and * examined by procarray.c, while fpLocalTransactionId is protected by - * backendLock and is used only by the locking subsystem. Doing it this + * backendLock and is used only by the locking subsystem. Doing it this * way makes it easier to verify that there are no funny race conditions. * * We don't bother recording this lock in the local lock table, since it's |