Re: POC: make mxidoff 64 bits - Mailing list pgsql-hackers

From Maxim Orlov
Subject Re: POC: make mxidoff 64 bits
Date
Msg-id CACG=ezaABYDepYf24MUNxc2oHRERxXbXHNMP+i-Pr1AXu26x0A@mail.gmail.com
Whole thread Raw
In response to Re: POC: make mxidoff 64 bits  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: POC: make mxidoff 64 bits
List pgsql-hackers
Unfortunately, I need to admit that I have messed a bit with v18.
I forgot to sync the pg_upgrade portion with the rest of the patch,
among other things. Here's a proper version with additional testing.

pg_upgrade/t/007_mxoff.pl is not meant to be committed, it's just
for test purposes. In order to run it, env var oldinstall must be set.

On Tue, 28 Oct 2025 at 17:17, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 27/10/2025 17:54, Maxim Orlov wrote:


If backend C looks up multixid 101 in between steps 3 and 4, it would
read the offset incorrectly, because 'base' isn't set yet.

Hmm, maybe I miss something? We set page base on first write of any
offset on the page, not only the first one. In other words, there
should never be a case when we read an offset without a previously
defined page base. Correct me if I'm wrong:
1. Backend A assigned mxact=100, offset=1000.
2. Backend B assigned mxact=101, offset=1010.
3. Backend B calls RecordNewMultiXact()/MXOffsetWrite() and
    set page base=1010, offset plus 0^0x80000000 bit while
    holding lock on the page.
4. Backend C looks up for the mxact=101 by calling MXOffsetRead()
    and should get exactly what he's looking for:
    base (1010) + offset (0) minus 0x80000000 bit.
5. Backend A calls RecordNewMultiXact() and sets his offset using
    existing base from step 3.


--
Best regards,
Maxim Orlov.
Attachment

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Skipping schema changes in publication
Next
From: wenhui qiu
Date:
Subject: Re: another autovacuum scheduling thread