Re: POC: make mxidoff 64 bits

wenhui qiu <qiuwenhuifx@gmail.com>

From: wenhui qiu <qiuwenhuifx@gmail.com>
To: Maxim Orlov <orlovmg@gmail.com>
Cc: Alexander Korotkov <aekorotkov@gmail.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-19T09:07:15Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix partial read handling in pg_upgrade's multixact conversion

  2. Increase timeout in multixid_conversion upgrade test

  3. Improve sanity checks on multixid members length

  4. Clarify comment on multixid offset wraparound check

  5. Never store 0 as the nextMXact

  6. Add runtime checks for bogus multixact offsets

  7. Widen MultiXactOffset to 64 bits

  8. Move pg_multixact SLRU page format definitions to a separate header

  9. Convert confusing macros in multixact.c to static inline functions

  10. Index SLRUs by 64-bit integers rather than by 32-bit integers

  11. Cope with possible failure of the oldest MultiXact to exist.

Hi Maxim
     Thank you for your feedback.I remember this path the primary
challenges are in the upgrade section, where we're still debating how to
address a few edge cases. Right now, this thread is missing input from core
code contributors.


Thanks

On Fri, Sep 19, 2025 at 12:37 AM Maxim Orlov <orlovmg@gmail.com> wrote:

>
> On Tue, 16 Sept 2025 at 15:12, wenhui qiu <qiuwenhuifx@gmail.com> wrote:
>
>>
>> Agree +1 , but I have a question: I remember the XID64 patch got split
>> into a few threads. How are these threads related? The original one was
>> seen as too big a change, so it was broken up after people raised
>> concerns.
>>
> Yeah, you're absolutely correct. This thread is a part of the overall
> work on the transition to XID64 in Postgres. As far as I remember, no
> one explicitly raised concerns, but it's clear to me that it won't be
> committed as one big patch set.
>
> Here is a WIP patch @ 8191e0c16a for the discussed above issue.
> I also had to merge several patches from the previous set, since the
> consensus is to use the PRI* format for outputting 64-bit values, and a
> separate patch that only changed the format with cast and %llu lost
> it's meaning.
>
> If this option suits everyone, the next step is to add a part related
> to the pg_upgrade.
>
> --
> Best regards,
> Maxim Orlov.
>