Re: POC: make mxidoff 64 bits
| От | Alexander Korotkov |
|---|---|
| Тема | Re: POC: make mxidoff 64 bits |
| Дата | |
| Msg-id | CAPpHfdsMd9TQ8ZbMnStMfFvBoBMwBCSC+8zcOYY9VDMYQzUYyQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: POC: make mxidoff 64 bits (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Ответы |
Re: POC: make mxidoff 64 bits
|
| Список | pgsql-hackers |
Hi, Heikki! On Tue, Nov 25, 2025 at 12:07 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote: > Looking at the upgrade code, in light of the "IPC/MultixactCreation on > the Standby server" thread [1], I think we need to make it more > tolerant. It's possible that there are 0 offsets in > pg_multixact/offsets. That might or might not be a problem: it's OK as > long as those multixids don't appear in any heap table, or you might > actually have lost those multixids, which is bad but the damage has > already been done and upgrade should not get stuck on it. > GetOldMultiXactIdSingleMember() currently asserts that the offset is > never zero, but it should try to do something sensible in that case > instead of just failing. Thank you for your work on this subject. It's very much appreciated. I'd like to raise the question about compression again. You have fairly criticized non-deterministic compression, but what do you think about deterministic one that I've proposed [1]. I understand that multixact offsets are subject of growth and their limit is not removed. However, it's still several extra gigabytes for multixact offsets, which we could save. Links. 1. https://www.postgresql.org/message-id/CAPpHfduDFLXATvBkUiOjyvZUBZXhK_pj5zjVpxvrJzkRVq%2B8Lw%40mail.gmail.com ------ Regards, Alexander Korotkov Supabase
В списке pgsql-hackers по дате отправления: