diff options
| author | Michael Paquier | 2023-07-26 03:06:04 +0000 |
|---|---|---|
| committer | Michael Paquier | 2023-07-26 03:06:04 +0000 |
| commit | 66d86d4201b3a4b05c6d7d1bf827d4b17aa44a06 (patch) | |
| tree | 4f0ed804218279e2d0a4be7d877e4eeb42f18ad3 /src/backend/storage | |
| parent | 62e9af4c63fbd36fb9af8450fb44bece76d7766f (diff) | |
Document more assumptions of LWLock variable changes with WAL inserts
This commit adds a few comments about what LWLockWaitForVar() relies on
when a backend waits for a variable update on its LWLocks for WAL
insertions up to an expected LSN.
First, LWLockWaitForVar() does not include a memory barrier, relying on
a spinlock taken at the beginning of WaitXLogInsertionsToFinish(). This
was hidden behind two layers of routines in lwlock.c. This assumption
is now documented at the top of LWLockWaitForVar(), and detailed at bit
more within LWLockConflictsWithVar().
Second, document why WaitXLogInsertionsToFinish() does not include
memory barriers, relying on a spinlock at its top, which is, per Andres'
input, fine for two different reasons, both depending on the fact that
the caller of WaitXLogInsertionsToFinish() is waiting for a LSN up to a
certain value.
This area's documentation and assumptions could be improved more in the
future, but at least that's a beginning.
Author: Bharath Rupireddy, Andres Freund
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/CALj2ACVF+6jLvqKe6xhDzCCkr=rfd6upaGc3477Pji1Ke9G7Bg@mail.gmail.com
Diffstat (limited to 'src/backend/storage')
| -rw-r--r-- | src/backend/storage/lmgr/lwlock.c | 11 |
1 files changed, 8 insertions, 3 deletions
diff --git a/src/backend/storage/lmgr/lwlock.c b/src/backend/storage/lmgr/lwlock.c index ffa865eb28a..315a78cda92 100644 --- a/src/backend/storage/lmgr/lwlock.c +++ b/src/backend/storage/lmgr/lwlock.c @@ -1556,9 +1556,10 @@ LWLockConflictsWithVar(LWLock *lock, pg_atomic_uint64 *valptr, uint64 oldval, /* * Test first to see if it the slot is free right now. * - * XXX: the caller uses a spinlock before this, so we don't need a memory - * barrier here as far as the current usage is concerned. But that might - * not be safe in general. + * XXX: the unique caller of this routine, WaitXLogInsertionsToFinish() + * via LWLockWaitForVar(), uses an implied barrier with a spinlock before + * this, so we don't need a memory barrier here as far as the current + * usage is concerned. But that might not be safe in general. */ mustwait = (pg_atomic_read_u32(&lock->state) & LW_VAL_EXCLUSIVE) != 0; @@ -1601,6 +1602,10 @@ LWLockConflictsWithVar(LWLock *lock, pg_atomic_uint64 *valptr, uint64 oldval, * * Note: this function ignores shared lock holders; if the lock is held * in shared mode, returns 'true'. + * + * Be aware that LWLockConflictsWithVar() does not include a memory barrier, + * hence the caller of this function may want to rely on an explicit barrier or + * an implied barrier via spinlock or LWLock to avoid memory ordering issues. */ bool LWLockWaitForVar(LWLock *lock, pg_atomic_uint64 *valptr, uint64 oldval, |
