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

Hi,

On 2026-01-24 21:00:00 +0200, Alexander Lakhin wrote:
> 16.01.2026 01:02, Tom Lane wrote:
> > Various buildfarm animals are complaining about fcb9c977a,
> > similarly to this from calliphoridae [1]:
>
> I've discovered another anomaly introduced with fcb9c977a, this time
> run-time:

With the other anomaly, you mean the spurious compiler warning or something
else?

> for i in `seq 300`; do
> echo "iteration $i"
>
> echo "
> create table t(f1 text);
> create index on t using spgist(f1);
> insert into t select 'a' from generate_series(1, 9000) g(i);
> vacuum analyze t;
> insert into t select 'b' from generate_series(1, 1000) g(i);
> drop table t;
> " | psql >/dev/null -v ON_ERROR_STOP=1 || break;
> done
>
> fails for me as below:
> ...
> iteration 39
> server closed the connection unexpectedly

Thanks for this report, particularly with the easy reproducer! How did you
find this?

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.

Greetings,

Andres Freund