,On Thu, Jan 6, 2022 at 4:15 PM Finnerty, Jim <jfinnert@amazon.com> wrote:
> (Maxim) Re: -- If after upgrade page has no free space for special data, tuples are
> converted to "double xmax" format: xmin became virtual
> FrozenTransactionId, xmax occupies the whole 64bit.
> Page converted to new format when vacuum frees enough space.
>
> A better way would be to prepare the database for conversion to the 64-bit XID format before the upgrade so that it
ensuresthat every page has enough room for the two new epochs (E bits).
>
> 1. Enforce the rule that no INSERT or UPDATE to an existing page will leave less than E bits of free space on a heap
page
>
> 2. Run an online and restartable task, analogous to pg_repack, that rewrites and splits any page that has less than E
bitsof free space. This needs to be run on all non-temp tables in all schemas in all databases. DDL operations are not
allowedon a target table while this operation runs, which is enforced by taking an ACCESS SHARE lock on each table
whilethe process is running. To mitigate the effects of this restriction, the restartable task can be restricted to run
onlyin certain hours. This could be implemented as a background maintenance task that runs for X hours as of a certain
timeof day and then kicks itself off again in 24-X hours, logging its progress.
>
> When this task completes, the database is ready for upgrade to 64-bit XIDs, and there is no possibility that any page
hasinsufficient free space for the special data.
>
> Would you agree that this approach would completely eliminate the need for a "double xmax" representation?
The "prepare" approach was the first tried.
https://github.com/postgrespro/pg_pageprep
But it appears to be very difficult and unreliable. After investing
many months into pg_pageprep, "double xmax" approach appears to be
very fast to implement and reliable.
------
Regards,
Alexander Korotkov