On 18/12/2025 19:03, Andres Freund wrote:
Hi,
On 2025-12-17 09:54:32 -0500, Andres Freund wrote:
On 2025-12-17 11:25:50 +0200, Heikki Linnakangas wrote:
- LWLockWaitListLock() uses pg_atomic_read_u32() after spinning,
LockBufHdr() retries directly with pg_atomic_fetch_or_u32().
I think here LWLockWaitListLock() is likely right - but it seems like a change
to LockBufHdr() that I would probably make in a separate commit?
FWIW, I couldn't come up with a scenario where it makes a performance
difference - exclusive content locks just aren't *that* frequent. And because
of that the wait list lock doesn't have similar contention as some non-content
lwlocks (like XidGenLock). The most extreme workload I could think of was
pgbench hammering a single sequence across many sessions. While the exclusive
locks show up in wait events, the buffer header spinlock itself doesn't..
So I'm inclined to not change anything about this for now.
Ok. My thinking was just that LockBufHdr() and LWLockWaitListLock()
should be consistent with each other. Otherwise anyone reading the code
will ask the question "why are they different?". They're the only two
things using the spin delay mechanism in our codebase, in addition to
actual spinlocks.
BTW, I wonder if it would be worthwhile to have an inlineable fast-path
of LockBufHdr() for the common case that the lock is free? I see that
UnlockBufHdr() is already a static inline function.
- Heikki
