Hi, On 2026-01-24 15:31:14 -0500, Andres Freund wrote: > I think this is more likely to be a spgist bug, not a bug in the patch. From > what I can tell, spgist tries to conditionally lock a buffer that it itself > already has locked exclusively - that's why the assertion is failing. > > I reproduced this locally, and could see in a bt full stack that the buffer > that spgist is trying to lock conditionally, is also referenced as > newInnerBuffer in doPickSplit(). So it's not an issue of bufmgr.c loosing > track of which buffers are locked with what mode. > > I haven't yet figured out why spgist ends up with a buffer it already is > using. > > 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. But I'm open to > going there anyway, just to avoid causing problems with previously "working" > code.
Looking at the spgist code, and the README, I think we may need to accept the uglines of silently failing when a backend tries to conditionally lock a buffer that it itself has already locked. Even though I still don't understand how it happens in this this specific case, that doesn't even have concurrency. Pretty ... not great ... that spgist does stuff like extending a relation while holding an exclusive buffer lock. Greetings, Andres Freund
