Message-ID: <fecc2b80-abe4-4fb7-9df9-3bbf54166eaa@iki.fi>
Date: Tue, 28 Oct 2025 16:17:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: POC: make mxidoff 64 bits
To: Maxim Orlov <orlovmg@gmail.com>, wenhui qiu <qiuwenhuifx@gmail.com>
Cc: Alexander Korotkov <aekorotkov@gmail.com>,
 Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
 Postgres hackers <pgsql-hackers@lists.postgresql.org>
References: 
 <CACG=ezaWg7_nt-8ey4aKv2w9LcuLthHknwCawmBgEeTnJrJTcw@mail.gmail.com>
 <e9507fef-da9a-4fe4-9fe1-5de2d7446547@iki.fi>
 <CAGjGUAK1Cpa5Sm0cJVX7iG-uKXpNC26BjWq8yJS40ZpCdenC4g@mail.gmail.com>
 <CACG=ezYiLzCSo43uTPzAeq8ZCnGSkAsw061=oMyw5J1NUZ9Jwg@mail.gmail.com>
 <CAExHW5soKc9mhLhroi__yrPD-ymkFbz=e5hyZ34iqjM-cdK9_g@mail.gmail.com>
 <CACG=ezaLdhpFY9_qr7B6s7kkg_=s5S_ZD2=dsSeBNgdWWWuKbg@mail.gmail.com>
 <CACG=ezaFoCx4XEGi4gQWrusYD81LTLTKBUdgs-mEjNwzVarRnw@mail.gmail.com>
 <CACG=ezarNdLaTdr3fdWGyVJEzRAa=Vd5LLmu7VN2r7XL6LH8xA@mail.gmail.com>
 <CAPpHfdtPybyMYBj-x3-Z5=4bj_vhYk2R0nezfy=Vjcz4QBMDgw@mail.gmail.com>
 <CACG=ezaCc4bFfua-VA1NB6wppMPwuMmZiGdrkb-iYK9ZmQa6gg@mail.gmail.com>
 <CAGjGUAJUmSFMunCcK8DXcjLrs2Hfk2kFiaWDTc6ti03S8Echmw@mail.gmail.com>
 <CACG=ezaCKR+--O2TZrm3jYGgpDjdpLXdz3marG6t_=nzP5+Gog@mail.gmail.com>
 <CAGjGUA+uxpbkRaxkZmcSNiGXJ_G3Zj4-gzaiy=94DH7rvE8tig@mail.gmail.com>
 <CACG=ezbPUASDL1eJ+c-ZkJMwRPukvp3EL0q1vSUa1h+fnX8y3g@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: 
 <CACG=ezbPUASDL1eJ+c-ZkJMwRPukvp3EL0q1vSUa1h+fnX8y3g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/fecc2b80-abe4-4fb7-9df9-3bbf54166eaa%40iki.fi>
Precedence: bulk

On 27/10/2025 17:54, Maxim Orlov wrote:
> Here is a new patch set @ 10b5bb3bffaee8
> 
> As previously stated, the patch set implements the concept of saving the
> "difference" between page offsets in order to save disc space.

Hmm, is that safe? We do the assignment of multixact and offset, in the 
GetNewMultiXactId() function, separately from updating the SLRU pages in 
the RecordNewMultiXact() function. I believe this happen:

To keep the arithmetic simple, let's assume that multixid 100 is the 
first multixid on an offsets SLRU page. So the 'base' on the page is 
initialized when multixid 100 is written.

1. Backend A calls GetNewMultiXactId(), is assigned multixid 100, offset 
1000
2. Backend B calls GetNewMultiXactId(), is assigned multixid 101, offset 
1010
3. Backend B calls RecordNewMultiXact() and sets 'page->offsets[1] = 10'
4. Backend A calls RecordNewMultiXact() and sets 'page->base = 1000' and 
'page->offsets[0] = 0'

If backend C looks up multixid 101 in between steps 3 and 4, it would 
read the offset incorrectly, because 'base' isn't set yet.

- Heikki