MIME-Version: 1.0
References: 
 <CACG=ezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@mail.gmail.com>
 <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>
 <36531c0e-292c-409d-bbc7-a252cf6e910a@iki.fi>
 <54aa8f65-f0e4-4464-b543-e0399c1cab1e@iki.fi>
 <CACG=ezYUJSvnuxntkURNWo_1vZ+AtmcQfqd_h6WgDzGaudfw+Q@mail.gmail.com>
 <4a9dda70-0af7-41a4-9636-b168f2fc48ef@iki.fi>
 <46cc45e9-fddd-44bc-bcb3-96889aafd921@iki.fi>
 <CAExHW5tUEkiQrvm9hgccjKUNkWBnJ5_HDUrAwiHBTxu+Vuj29Q@mail.gmail.com>
 <6c298bc4-7029-4c1d-bf16-3e094842ce32@iki.fi>
 <CAExHW5t3kzJiVqmoqCLyGmfkTjD4Rwa27kXH-S_XvHWLkM2fzw@mail.gmail.com>
 <CAExHW5ucnoyjd6p7UVVhQTeV7hc8-vX81ti8f7sU0COqfUWzQg@mail.gmail.com>
 <2c62322e-a0e3-49cd-b369-370718a8efd8@iki.fi>
 <22d30907-03b0-47c7-b38e-5574e475a387@iki.fi>
In-Reply-To: <22d30907-03b0-47c7-b38e-5574e475a387@iki.fi>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: Mon, 8 Dec 2025 21:20:23 +0530
Message-ID: 
 <CAExHW5uodjif=JBfB3_rFt4hx-rgPfveAtESCkg1dw-qxk5uMw@mail.gmail.com>
Subject: Re: POC: make mxidoff 64 bits
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Maxim Orlov <orlovmg@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Alexander Korotkov <aekorotkov@gmail.com>,
 wenhui qiu <qiuwenhuifx@gmail.com>,
	Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAExHW5uodjif%3DJBfB3_rFt4hx-rgPfveAtESCkg1dw-qxk5uMw%40mail.gmail.com>
Precedence: bulk

On Mon, Dec 8, 2025 at 6:32=E2=80=AFPM Heikki Linnakangas <hlinnaka@iki.fi>=
 wrote:
>
> On 06/12/2025 01:36, Heikki Linnakangas wrote:
> > On 05/12/2025 15:42, Ashutosh Bapat wrote:
> >> + $newnode->start;
> >> + my $new_dump =3D get_dump_for_comparison($newnode, "newnode_${tag}
> >> _dump");
> >> + $newnode->stop;
> >>
> >>
> >> There is no code which actually looks at the multixact offsets here to
> >> make sure that the conversion happened correctly. I guess the test
> >> relies on visibility checks for that. Anyway, we need a comment
> >> explaining why just comparing the contents of the table is enough to
> >> ensure correct conversion. Better if we can add an explicit test that
> >> the offsets were converted correctly. I don't have any idea of how to
> >> do that right now, though. Maybe use pg_get_multixact_members()
> >> somehow in the query to extract data out of the table?
> >
> > Agreed, the verification here is quite weak. I didn't realize that
> > pg_get_multixact_members() exists! That might indeed be handy here, but
> > I'm not sure how exactly to construct the test. A direct C function lik=
e
> > test_create_multixact() in test_multixact.c would be handy here, but
> > we'd need to compile and do run that in the old cluster, which seems
> > difficult.
>
> I added verification of all the multixids between oldest and next
> multixid, using pg_get_multixact_members(). The test now calls
> pg_get_multixact_members() for all updating multixids in the range,
> before and after the upgrade, and compares the results.

I thought about adding pg_get_multixact_member in
get_test_table_contents() itself like SELECT ctid, xmin, xmax,
get_multixact_member(xmin), get_multixact_member(xmax) * FROM
mxofftest; but then I realized that the UPDATE would replace mxids by
actual transaction ids in the visible rows. So that can't be used.
What you have done doesn't have that drawback, but it's also not
checking whether the multixids in (invisible) rows are reachable in
offsets and members. But probably that's too hard to do and is covered
by visibility checks.

--=20
Best Wishes,
Ashutosh Bapat