public inbox for [email protected]  
help / color / mirror / Atom feed
From: Heikki Linnakangas <[email protected]>
To: Maxim Orlov <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Alexander Korotkov <[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: Wed, 26 Nov 2025 17:50:25 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CACG=ezY0=ri8A0duXbpd1XNUc1jnngaPnmB0-+UZpxAv7-fNtw@mail.gmail.com>
References: <CACG=ezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@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]>
	<CACG=ezY0=ri8A0duXbpd1XNUc1jnngaPnmB0-+UZpxAv7-fNtw@mail.gmail.com>

On 26/11/2025 17:23, Maxim Orlov wrote:
> On Tue, 25 Nov 2025 at 13:07, Heikki Linnakangas <[email protected] 
> <mailto:[email protected]>> wrote:
>> GetOldMultiXactIdSingleMember() currently asserts that the offset is
>> never zero, but it should try to do something sensible in that case
>> instead of just failing.
> 
> Correct me if I'm wrong, but we added the assertion that offsets are
> never 0, based on the idea that case #2 will never take place during an
> update. If this isn't the case, this assertion could be removed.
> The rest of the function appears to work correctly.
> 
> I even think that, as an experiment, we could randomly reset some of the
> offsets to zero and nothing would happen, except that some data would
> be lost.

+1

> The most sensible thing we can do is give the user a warning, right?
> Something like, "During the update, we encountered some weird offset
> that shouldn't have been there, but there's nothing we can do about it,
> just take note."

Yep, makes sense.

- Heikki






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: <[email protected]>

* 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