On Tue, Aug 11, 2026 at 7:47 PM Andres Freund <andres@anarazel.de> wrote:
You absolutely, definitely, never, ever ever may hold a spinlock over something even remotely as complicated like an lwlock or a hashtable delete. NEVER.
So, the problem of spin locks there is that the contenders will spend
CPU on this loop right?
while (old_buf_state & BM_LOCKED) { perform_spin_delay(&delayStatus); old_buf_state = pg_atomic_read_u64(&desc->state); } And since there is a perform_spin_delay there I assume it is not 100%
I imagined this was tuned to use maybe 1% CPU.
If not, can't we simply use an exponentially increasing sleep until we get
to say 1ms and that uses virtually 0 CPU while waiting.
And without that the patch is completely unsafe.
And with that is it safe? Pretending LockBufHdr not to be a spin-lock.
