On Sat, Jan 24, 2026 at 4:12 PM Tom Lane <[email protected]> wrote: > Andres Freund <[email protected]> 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
