Re: POC: make mxidoff 64 bits

Maxim Orlov <orlovmg@gmail.com>

From: Maxim Orlov <orlovmg@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Alexander Korotkov <aekorotkov@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, wenhui qiu <qiuwenhuifx@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: 2025-12-04T10:03:23Z
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 Wed, 3 Dec 2025 at 15:04, Heikki Linnakangas <hlinnaka@iki.fi> wrote:

>
> There are plenty of such critical bytes in the system where a single bit
> flip renders the whole block unreadable. Actually, if we had checksums
> on SLRU pages, a single bit flip anywhere in the page would make the
> checksum fail and render the block unreadable.
>
> Correct. However, my concern about the lack of checksums for SLRU wasn't
about data loss and the impossibility of recovering it, but about the
impossibility of detecting the error.  But it is how it is for now.

-- 
Best regards,
Maxim Orlov.