Re: Buffer locking is special (hints, checksums, AIO writes)

On Sat, Jan 24, 2026 at 4:12 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > We could of course just accept this case and have the conditional lock
> > acquisition fail, but I think trying to conditionally lock a buffer that you
> > already lock is indicative of something having gone wrong.
>
> I don't really buy this argument. Yes, within a single function it'd
> be silly to lock a buffer and immediately try to lock it again, but
> when you consider cases like recursive modifications of index state,
> it's *far* from obvious that some lower recursion level might not try
> to lock a buffer that some outer level already locked. In the case at
> hand I think it is probably driven by two recursion levels trying to
> acquire free space out of the same buffer.

Even nbtree has to deal with this. Also in the context of free space
management. See the comments in _bt_allocbuf, particularly the ones
where we explicitly describe a common scenario where we conditionally
lock a buffer that our own caller/backend already has a lock on.

I actually agree with Andres' general sentiment about this kind of
coding pattern; it also seems sloppy to me. But it's hard to see how
we could do better in places such as _bt_allocbuf. At least within the
confines of the current FSM design.

--
Peter Geoghegan