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.
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 |