On Tue, Aug 11, 2026, 20:26 Alexandre Felipe <[email protected]> wrote:
> > On Tue, Aug 11, 2026 at 7:47 PM Andres Freund <[email protected]> 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. > > Thank you for your quick response Andres > > Regards, > Alexandre >
