From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Alexander Lakhin <exclusion@gmail.com>, Chao Li <li.evan.chao@gmail.com>,
        Kirill Reshke <reshkekirill@gmail.com>,
        Heikki Linnakangas <hlinnaka@iki.fi>,
        Melanie Plageman <melanieplageman@gmail.com>,
        Matthias van de Meent <boekewurm+postgres@gmail.com>,
        pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>,
        Noah Misch <noah@leadboat.com>, Robert Haas <robertmhaas@gmail.com>,
        Michael Paquier <michael.paquier@gmail.com>
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
In-reply-to: <cf7prit6zlr64ekyf7ev4x2jxporxplcjnoq6sao3nbrpawtj7@65mndedqeqm2>
References: <vrnib3bf726ht72jlccu252qm65lzexutydtagytstsjszpiya@ece6xi7o4nfx>
 <F6A52B41-2FFA-4592-BD9B-0438F610B6A2@gmail.com>
 <cj5mcjdpucvw4a54hehslr3ctukavrbnxltvuzzhqnimvpju5e@cy3g3mnsefwz>
 <58821140-0182-4FF3-9A4F-5B168DDB9243@gmail.com>
 <732580B4-962F-4EBD-8811-F4667D79747D@gmail.com>
 <wat7azo4hpgux7ptvozfedtw6hnz7pih3vvnfipxdlcci6fuf3@wacut36qcac7>
 <934395.1768518154@sss.pgh.pa.us>
 <90bd2cbb-49ce-4092-9f61-5ac2ab782c94@gmail.com>
 <esihk6vohorlopugumy6ps6zmyh7cgkwi66trm4ocpbkqa4i2i@g5j2hvbzv4lp>
 <3472929.1769289107@sss.pgh.pa.us>
 <cf7prit6zlr64ekyf7ev4x2jxporxplcjnoq6sao3nbrpawtj7@65mndedqeqm2>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sat, 24 Jan 2026 18:03:00 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3496574.1769302476.1@sss.pgh.pa.us>
Date: Sat, 24 Jan 2026 19:54:36 -0500
Message-ID: <3496575.1769302476@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3496575.1769302476%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2026-01-24 16:11:47 -0500, Tom Lane wrote:
>> 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.  SPGist is expecting
>> the lower level to fail to get the lock and then go find some free space
>> elsewhere.  Yeah, we could probably re-code it to get that outcome in
>> another way, but why?

> Regardless of the assertion, it still feels like there may be something off
> here. Why is the page marked as empty in the FSM, despite actually not being
> empty?

Who said anything about its being empty?  There's X amount of space
used on the page now, the outer level is preparing to add a tuple
of size Y, the inner level is looking for a place to put a tuple
of size Z.  As long as X+Y+Z <= 8K, there's no free-space-related
reason the page wouldn't work for this.  We could actually try to
make it work, but that seems fragile to me: the outer level would
have to be prepared for the possibility that the page changes
under it despite holding exclusive lock.  I think it's reasonable
on complexity grounds to insist that the inner recursion level
go play someplace else.

			regards, tom lane