Re: [PATCH] bufmgr: tighten LWLock:BufferMapping on InvalidateBuffer

Hi,

On 2026-08-11 20:32:40 +0100, Alexandre Felipe wrote:
> On Tue, Aug 11, 2026, 20:26 Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>
> wrote:
>
> >
> > On Tue, Aug 11, 2026 at 7:47 PM Andres Freund <andres(at)anarazel(dot)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.

It already uses exponential backoff, via perform_spin_delay().

I went into some detail why this is not ok in
https://postgr.es/m/bk5cbayf3q4yll4fqs2wbmonzhykg43k2k5v37vokkko53ebsd%40spcp4mxlb7hb

This specific change looks like it'd be flat out broken even without the
spinlock error recovery concerns, due to causing undetected deadlocks. You
can't just change the nesting of locks in one place.

Greetings,

Andres Freund