Re: Orphan page in _bt_split - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Orphan page in _bt_split
Date
Msg-id 1bfe94b4-464e-414c-9bd9-fbae6cc24036@garret.ru
Whole thread Raw
In response to Re: Orphan page in _bt_split  (Michael Paquier <michael@paquier.xyz>)
List 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.





pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Get rid of pgstat_count_backend_io_op*() functions
Next
From: Ajin Cherian
Date:
Subject: Re: Improve pg_sync_replication_slots() to wait for primary to advance