Re: POC: make mxidoff 64 bits

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Maxim Orlov <orlovmg(at)gmail(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>
Cc: Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: POC: make mxidoff 64 bits
Date: 2025-10-28 14:17:11
Message-ID: fecc2b80-abe4-4fb7-9df9-3bbf54166eaa@iki.fi
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey Prokhorenko 2025-10-28 14:28:54 Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions
Previous Message Álvaro Herrera 2025-10-28 14:05:34 Re: Consistently use the XLogRecPtrIsInvalid() macro