Re: Orphan page in _bt_split
От | Konstantin Knizhnik |
---|---|
Тема | Re: Orphan page in _bt_split |
Дата | |
Msg-id | 1bfe94b4-464e-414c-9bd9-fbae6cc24036@garret.ru обсуждение исходный текст |
Ответ на | Re: Orphan page in _bt_split (Michael Paquier <michael@paquier.xyz>) |
Список | 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 по дате отправления: