public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alexander Korotkov <[email protected]>
To: Heikki Linnakangas <[email protected]>
Cc: Maxim Orlov <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: wenhui qiu <[email protected]>
Cc: Postgres hackers <[email protected]>
Cc: Ashutosh Bapat <[email protected]>
Subject: Re: POC: make mxidoff 64 bits
Date: Tue, 2 Dec 2025 16:11:34 +0200
Message-ID: <CAPpHfdsMd9TQ8ZbMnStMfFvBoBMwBCSC+8zcOYY9VDMYQzUYyQ@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CACG=ezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@mail.gmail.com>
<[email protected]>
<CACG=ezbKwypBp=14q9+hMQApus3=1hKxJ9x1+KinUhtT48570Q@mail.gmail.com>
<[email protected]>
<CACG=ezZwdvsijzuXE3hex3xHcoz75EQYBXRTsQJVwbo5J5sS3g@mail.gmail.com>
<CACG=ezbs912S58=uR17b4w8uuWv1=OcCRaTW_OWdFm4+tXZA6w@mail.gmail.com>
<CAGjGUA+BfcWyccNN4=tHsW_E-koRxbg8h8ut6hjvPsHMgmek6w@mail.gmail.com>
<CACG=ezYbYO_KHWdeDedbDcY0tOS0JfaqBxG3=bG5+DdsDK4MpQ@mail.gmail.com>
<CACG=ezYpZRPwoRCz_h3Qerd3XJNdpTHCpwGbZphNdy26tA4_qQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<CACG=ezYUJSvnuxntkURNWo_1vZ+AtmcQfqd_h6WgDzGaudfw+Q@mail.gmail.com>
<[email protected]>
<[email protected]>
<CAExHW5tUEkiQrvm9hgccjKUNkWBnJ5_HDUrAwiHBTxu+Vuj29Q@mail.gmail.com>
<[email protected]>
<[email protected]>
Hi, Heikki!
On Tue, Nov 25, 2025 at 12:07 PM Heikki Linnakangas <[email protected]> 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.g...
------
Regards,
Alexander Korotkov
Supabase
view thread (79+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: POC: make mxidoff 64 bits
In-Reply-To: <CAPpHfdsMd9TQ8ZbMnStMfFvBoBMwBCSC+8zcOYY9VDMYQzUYyQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox