@@ -314,18 +314,18 @@ A performs a store, A and B both acquire an LWLock in either order, and B
314314then performs a load on the same memory location, it is guaranteed to see
315315A's store. In this case, each backend's fast-path lock queue is protected
316316by an LWLock. A backend wishing to acquire a fast-path lock grabs this
317- LWLock before examiningFastPathStrongLocks to check for the presence of a
318- conflicting strong lock. And the backend attempting to acquire a strong
317+ LWLock before examiningFastPathStrongRelationLocks to check for the presence of
318+ a conflicting strong lock. And the backend attempting to acquire a strong
319319lock, because it must transfer any matching weak locks taken via the fast-path
320320mechanism to the shared lock table, will acquire every LWLock protecting
321- a backend fast-path queue in turn.Thus , if we examineFastPathStrongLocks
321+ a backend fast-path queue in turn.So , if we examineFastPathStrongRelationLocks
322322and see a zero, then either the value is truly zero, or if it is a stale value,
323323the strong locker has yet to acquire the per-backend LWLock we now hold (or,
324324indeed, even the first per-backend LWLock) and will notice any weak lock we
325325take when it does.
326326
327- Fast-path VXID locks do not use theFastPathStrongLocks table. The first
328- lock taken on a VXID is always the ExclusiveLock taken by its owner. Any
327+ Fast-path VXID locks do not use theFastPathStrongRelationLocks table. The
328+ first lock taken on a VXID is always the ExclusiveLock taken by its owner. Any
329329subsequent lockers are share lockers waiting for the VXID to terminate.
330330Indeed, the only reason VXID locks use the lock manager at all (rather than
331331waiting for the VXID to terminate via some other method) is for deadlock