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
