Re: Orphan page in _bt_split

Konstantin Knizhnik <knizhnik@garret.ru>

From: Konstantin Knizhnik <knizhnik@garret.ru>
To: Michael Paquier <michael@paquier.xyz>, Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-03T06:25:33Z
Lists: pgsql-hackers
On 02/09/2025 7:42 AM, Michael Paquier wrote:
> On Mon, Sep 01, 2025 at 02:35:56PM -0400, Peter Geoghegan wrote:
>> I remember that when I worked on what became commit 9b42e71376 back in
>> 2019 (which fixed a similar problem caused by the INCLUDE index
>> patch), Tom suggested that we do things this way defensively (without
>> being specifically aware of the _bt_getbuf hazard). That does seem
>> like the best approach.
>>
>> I'm a little bit worried about the added overhead of allocating an
>> extra BLCKSZ buffer for this. I wonder if it would make sense to use
>> BLCKSZ arrays of char for both of the temp pages.
> Hmm.  Yes, the allocation makes me a bit uneasy.  Or it would be
> possible to just use a PGAlignedBlock here?  That's already used in
> some code paths for page manipulations, forcing alignment.


Do you suggest to replace `PageGetTempPage` with using local buffers?
Or may be change `PageGetTempPage*` to accept parameter with provided 
local buffer?
But it is used in ~20 places. Change them all?
It seems to be too invasive change for such small fix, but I can do it.

Certainly copying data can be done in more efficient way, but I do not 
thing that palloc here can have any noticeable impact on performance.
Please let me know if I should prepare new page avoiding memory 
allocation or you prefer to do it yourself.