Horton

Re: POC: make mxidoff 64 bits

Maxim Orlov <orlovmg@gmail.com>

View thread
From: Maxim Orlov <orlovmg@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@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>
Date: 2025-12-11T12:47:53Z
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.

On Thu, 11 Dec 2025 at 10:58, Heikki Linnakangas <hlinnaka@iki.fi> wrote:

>
> That's a great question and I've been wondering about it myself. It goes
> all the way to the initial commit where multixacts were introduced, and
> I don't see any particular reason for it even back then. Even in the
> very first version of multixact.c, IMO it would've been simpler to have
> the writer handle the wraparound.
>
> +1 This code is quite old. I don't see any particular reason for doing
it that way. Unfortunately, we were unable to prove the absence of
something, namely errors, in this instance. But there were no obvious
statements on why it should be in this manner. So, for me, it's much
clearer to increment and handle wraparound in one place rather
than spread it across multiple calls in the module.

-- 
Best regards,
Maxim Orlov.