Document more assumptions of LWLock variable changes with WAL inserts
authorMichael Paquier <michael@paquier.xyz>
Wed, 26 Jul 2023 03:06:04 +0000 (12:06 +0900)
committerMichael Paquier <michael@paquier.xyz>
Wed, 26 Jul 2023 03:06:04 +0000 (12:06 +0900)
commit66d86d4201b3a4b05c6d7d1bf827d4b17aa44a06
tree4f0ed804218279e2d0a4be7d877e4eeb42f18ad3
parent62e9af4c63fbd36fb9af8450fb44bece76d7766f
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
src/backend/access/transam/xlog.c
src/backend/storage/lmgr/lwlock.c