Message-ID: <2c7d4202-31d4-4254-8ed0-484083b14624@iki.fi>
Date: Thu, 11 Dec 2025 09:58:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: POC: make mxidoff 64 bits
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
 Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Maxim Orlov <orlovmg@gmail.com>, Alexander Korotkov
 <aekorotkov@gmail.com>, wenhui qiu <qiuwenhuifx@gmail.com>,
 Postgres hackers <pgsql-hackers@lists.postgresql.org>
References: 
 <CACG=ezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@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>
 <CAExHW5s_uNeD_xYjdbSR8khMXwWJQOY9Qg=j4T+5KOfGz5-RsQ@mail.gmail.com>
 <3624730d-6dae-42bf-9458-76c4c965fb27@iki.fi>
 <b3e13089-fa03-4241-b203-1ba140ef86dc@iki.fi>
 <CAExHW5t6Qjw42V1-XuL22bkZ3YvMPfZn8vgDw3ED7VpcjOcTfQ@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: 
 <CAExHW5t6Qjw42V1-XuL22bkZ3YvMPfZn8vgDw3ED7VpcjOcTfQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/2c7d4202-31d4-4254-8ed0-484083b14624%40iki.fi>
Precedence: bulk

On 11/12/2025 05:06, Ashutosh Bapat wrote:
> On Thu, Dec 11, 2025 at 12:49 AM Heikki Linnakangas <hlinnaka@iki.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.

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.

Álvaro, would you happen to remember?

- Heikki