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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
Date: 2026-01-25 00:54:36
Message-ID: 3496575.1769302476@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-01-25 00:56:52 Re: ABI Compliance Checker GSoC Project
Previous Message Michael Paquier 2026-01-25 00:46:51 Re: Some tests for TOAST, STORAGE MAIN/EXTENDED