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 ee94725bb86998247f29594921735c21627d76af..3c7c9e55e8b23b6a70063a96257ae98195049175 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 568de68beba60013de277307c68d6f77797c5ce5..a216fb90aec63daa6ec5614f6f40a3e05f0646da 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 92b6d9d1b429d3418ef374a6537375274bc2a7e7..faddef579c707c709f728973e87cbf7fafb11a16 100644 (file)
--- a/src/include/storage/lock.h
+++ b/src/include/storage/lock.h
@@ -412,7 +412,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;