Re: POC: make mxidoff 64 bits

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Maxim Orlov <orlovmg(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: POC: make mxidoff 64 bits
Date: 2025-12-11 03:06:11
Message-ID: CAExHW5t6Qjw42V1-XuL22bkZ3YvMPfZn8vgDw3ED7VpcjOcTfQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 11, 2025 at 12:49 AM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
> On 09/12/2025 14:00, Heikki Linnakangas wrote:
> > 1. Currently, at multixid wraparound, MultiXactState->nextMXact goes to
> > 0, which is invalid. All the readers must be prepared for that, and skip
> > over the 0. That's error-prone, we've already missed that a few times.
> > Let's change things so that the code that *writes* MultiXactState-
> > >nextMXact skips over the zero already.
>
> Here's a patch for that. Does anyone see a problem with this?

The patch looks fine to me. It simplifies readers without affecting
writers much. I was expecting more explanation of why it wasn't done
that way to start with and why is it safe to do so (now, if
applicable). There must be a reason why we chose to make readers
handle invalid mxid instead of writers writing one. If it's for
performance reasons then does the new arrangement cause any
regression? If it's for safety reasons, are we fixing one set of
problems but introducing a new set. I was expecting commit message to
answer those questions.

--
Best Wishes,
Ashutosh Bapat

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2025-12-11 03:07:03 Re: Improve pg_sync_replication_slots() to wait for primary to advance
Previous Message John Naylor 2025-12-11 02:53:09 Re: Add a greedy join search algorithm to handle large join problems