(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?
/Jim
