From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Alexander Lakhin <exclusion@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>
Cc: Kirill Reshke <reshkekirill@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Melanie Plageman <melanieplageman@gmail.com>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>
Cc: pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>
Cc: Noah Misch <noah@leadboat.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael.paquier@gmail.com>
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
Date: Sat, 24 Jan 2026 19:54:36 -0500
Message-ID: <3496575.1769302476@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, exclusion@gmail.com, li.evan.chao@gmail.com, reshkekirill@gmail.com, hlinnaka@iki.fi, melanieplageman@gmail.com, boekewurm+postgres@gmail.com, thomas.munro@gmail.com, noah@leadboat.com, robertmhaas@gmail.com, michael.paquier@gmail.com
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
In-Reply-To: <3496575.1769302476@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox