Hi Andres,
Thanks for your response.
To answer your questions:
>> 3. A flag to identify if the page is a relational or BufferedObject
>Why is this needed in the page header?
Now that we are dealing with two different type of page headers, we need to
know how to interpret any given page. We need to use pd_flags to determine this.
>How are you proposing to deal with this in the "key" to "offset in >SLRU"
>mapping? E.g. converting a xid to an offset in the pg_xact SLRU. I >assume
>you're thinking to deal with this by making the conversion math a bit >more
>complicated?
You’re right; we would have to account for this in the conversion math between
the ‘key’ and ‘offset’. The change to the macros would be as following:
#define MULTIXACT_OFFSETS_PER_PAGE ((BLCKSZ -
SizeOfBufferedObjectPageHeaderData) / sizeof(MultiXactOffset))
Additionally, we need to account for the size of the page header when reading
and writing multixacts in memory based off of the entryno.
Rishu Bagga
Amazon Web Services (AWS)
On 6/22/22, 2:40 PM, "Andres Freund" <and...@anarazel.de> wrote:
Hi,
On 2022-06-22 21:06:29 +0000, Bagga, Rishu wrote:
> 3. A flag to identify if the page is a relational or BufferedObject
Why is this needed in the page header?
> Using the new BufferedObject page header will be space efficient but
> introduces a significant change in the codebase to now track two types
> of page header data. During upgrade, all SLRU files that exist on the
> system must be converted to the new format with page header. This will
> require rewriting all the SLRU pages with the page header as part of
> pg_upgrade.
How are you proposing to deal with this in the "key" to "offset in SLRU"
mapping? E.g. converting a xid to an offset in the pg_xact SLRU. I assume
you're thinking to deal with this by making the conversion math a bit more
complicated?
Greetings,
Andres Freund
