,On Thu, Jan 6, 2022 at 4:15 PM Finnerty, Jim <jfinn...@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 ensures that 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 bits of free space. This needs to be > run on all non-temp tables in all schemas in all databases. DDL operations > are not allowed on a target table while this operation runs, which is > enforced by taking an ACCESS SHARE lock on each table while the process is > running. To mitigate the effects of this restriction, the restartable task > can be restricted to run only in certain hours. This could be implemented as > a background maintenance task that runs for X hours as of a certain time of > 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 has insufficient 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
