Re: POC: make mxidoff 64 bits - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: POC: make mxidoff 64 bits
Date
Msg-id fecc2b80-abe4-4fb7-9df9-3bbf54166eaa@iki.fi
Whole thread Raw
In response to Re: POC: make mxidoff 64 bits  (Maxim Orlov <orlovmg@gmail.com>)
List 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




pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: Consistently use the XLogRecPtrIsInvalid() macro
Next
From: Sergey Prokhorenko
Date:
Subject: Re: Add uuid_to_base32hex() and base32hex_to_uuid() built-in functions