Re: Orphan page in _bt_split

From: Konstantin Knizhnik <knizhnik(at)garret(dot)ru>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Orphan page in _bt_split
Date: 2025-09-03 06:25:33
Message-ID: 1bfe94b4-464e-414c-9bd9-fbae6cc24036@garret.ru
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajin Cherian 2025-09-03 06:28:02 Re: Improve pg_sync_replication_slots() to wait for primary to advance
Previous Message Michael Paquier 2025-09-03 05:47:51 Re: Get rid of pgstat_count_backend_io_op*() functions