Finish rename of FastPathStrongLocks to FastPathStrongRelationLocks.

Commit 8e5ac74c1249820ca55481223a95b9124b4a4f95 tried to do this renaming,
but I relied on gcc to tell me where I needed to make changes, instead of
grep.

Noted by Jeff Davis.

diff --git a/src/backend/storage/lmgr/README b/src/backend/storage/lmgr/README
index 13ccb0b8f93fc658ce2e15194001e09825e33f17..88b451248b012adb4928483cd6ea536f78964d66 100644 (file)
--- a/src/backend/storage/lmgr/README
+++ b/src/backend/storage/lmgr/README
@@ -314,18 +314,18 @@ A performs a store, A and B both acquire an LWLock in either order, and B
 then performs a load on the same memory location, it is guaranteed to see
 A's store.  In this case, each backend's fast-path lock queue is protected
 by an LWLock.  A backend wishing to acquire a fast-path lock grabs this
-LWLock before examining FastPathStrongLocks to check for the presence of a
-conflicting strong lock.  And the backend attempting to acquire a strong
+LWLock before examining FastPathStrongRelationLocks to check for the presence of
+a conflicting strong lock.  And the backend attempting to acquire a strong
 lock, because it must transfer any matching weak locks taken via the fast-path
 mechanism to the shared lock table, will acquire every LWLock protecting
-a backend fast-path queue in turn.  Thus, if we examine FastPathStrongLocks
+a backend fast-path queue in turn.  So, if we examine FastPathStrongRelationLocks
 and see a zero, then either the value is truly zero, or if it is a stale value,
 the strong locker has yet to acquire the per-backend LWLock we now hold (or,
 indeed, even the first per-backend LWLock) and will notice any weak lock we
 take when it does.
 
-Fast-path VXID locks do not use the FastPathStrongLocks table.  The first
-lock taken on a VXID is always the ExclusiveLock taken by its owner.  Any
+Fast-path VXID locks do not use the FastPathStrongRelationLocks table.  The
+first lock taken on a VXID is always the ExclusiveLock taken by its owner.  Any
 subsequent lockers are share lockers waiting for the VXID to terminate.
 Indeed, the only reason VXID locks use the lock manager at all (rather than
 waiting for the VXID to terminate via some other method) is for deadlock

diff --git a/src/backend/storage/lmgr/lock.c b/src/backend/storage/lmgr/lock.c
index 65f64ffa7f8c7b9c47a0e06fefc5bdc0488c0504..6fe1520d7c4911ca1bcf4a5f0b6d1d35b0e1bb68 100644 (file)
--- a/src/backend/storage/lmgr/lock.c
+++ b/src/backend/storage/lmgr/lock.c
@@ -723,8 +723,8 @@ LockAcquireExtended(const LOCKTAG *locktag,
                        /*
                         * LWLockAcquire acts as a memory sequencing point, so it's safe
                         * to assume that any strong locker whose increment to
-                        * FastPathStrongLocks->counts becomes visible after we test it has
-                        * yet to begin to transfer fast-path locks.
+                        * FastPathStrongRelationLocks->counts becomes visible after we test
+                        * it has yet to begin to transfer fast-path locks.
                         */
                        LWLockAcquire(MyProc->backendLock, LW_EXCLUSIVE);
                        if (FastPathStrongRelationLocks->count[fasthashcode] != 0)

diff --git a/src/include/storage/lock.h b/src/include/storage/lock.h
index 0b561159ee7a1b5465eb85db94609dff3b8ed5db..17a2454494fe7d276d5bcfe34451686a48dad17a 100644 (file)
--- a/src/include/storage/lock.h
+++ b/src/include/storage/lock.h
@@ -414,7 +414,7 @@ typedef struct LOCALLOCK
        int64           nLocks;                 /* total number of times lock is held */
        int                     numLockOwners;  /* # of relevant ResourceOwners */
        int                     maxLockOwners;  /* allocated size of array */
-       bool            holdsStrongLockCount;   /* did we bump FastPathStrongLocks? */
+       bool            holdsStrongLockCount;   /* bumped FastPathStrongRelatonLocks? */
        LOCALLOCKOWNER *lockOwners; /* dynamically resizable array */
 } LOCALLOCK;