Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit4a6fab0

Browse files
committed
Finish rename of FastPathStrongLocks to FastPathStrongRelationLocks.
Commit8e5ac74 tried to do this renaming,but I relied on gcc to tell me where I needed to make changes, instead ofgrep.Noted by Jeff Davis.
1 parent53c5b86 commit4a6fab0

File tree

3 files changed

+8
-8
lines changed

3 files changed

+8
-8
lines changed

‎src/backend/storage/lmgr/README

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -314,18 +314,18 @@ A performs a store, A and B both acquire an LWLock in either order, and B
314314
then performs a load on the same memory location, it is guaranteed to see
315315
A's store. In this case, each backend's fast-path lock queue is protected
316316
by 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+
aconflicting strong lock. And the backend attempting to acquire a strong
319319
lock, because it must transfer any matching weak locks taken via the fast-path
320320
mechanism 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
322322
and see a zero, then either the value is truly zero, or if it is a stale value,
323323
the strong locker has yet to acquire the per-backend LWLock we now hold (or,
324324
indeed, even the first per-backend LWLock) and will notice any weak lock we
325325
take 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+
firstlock taken on a VXID is always the ExclusiveLock taken by its owner. Any
329329
subsequent lockers are share lockers waiting for the VXID to terminate.
330330
Indeed, the only reason VXID locks use the lock manager at all (rather than
331331
waiting for the VXID to terminate via some other method) is for deadlock

‎src/backend/storage/lmgr/lock.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -723,8 +723,8 @@ LockAcquireExtended(const LOCKTAG *locktag,
723723
/*
724724
* LWLockAcquire acts as a memory sequencing point, so it's safe
725725
* to assume that any strong locker whose increment to
726-
*FastPathStrongLocks->counts becomes visible after we test it has
727-
* yet to begin to transfer fast-path locks.
726+
*FastPathStrongRelationLocks->counts becomes visible after we test
727+
*it hasyet to begin to transfer fast-path locks.
728728
*/
729729
LWLockAcquire(MyProc->backendLock,LW_EXCLUSIVE);
730730
if (FastPathStrongRelationLocks->count[fasthashcode]!=0)

‎src/include/storage/lock.h

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -412,7 +412,7 @@ typedef struct LOCALLOCK
412412
int64nLocks;/* total number of times lock is held */
413413
intnumLockOwners;/* # of relevant ResourceOwners */
414414
intmaxLockOwners;/* allocated size of array */
415-
boolholdsStrongLockCount;/*did we bump FastPathStrongLocks? */
415+
boolholdsStrongLockCount;/*bumped FastPathStrongRelatonLocks? */
416416
LOCALLOCKOWNER*lockOwners;/* dynamically resizable array */
417417
}LOCALLOCK;
418418

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp