We intend to do the following work on the patch soon:
1. Write a detailed README
2. Split the patch into several pieces including a separate part for XID_FMT. But if committers meanwhile choose to commit Jim's XID_FMT patch we also appreciate this and will rebase our patch accordingly.
2A. Probably refactor it to store precalculated XMIN/XMAX in memory tuple representation instead of t_xid_base/t_multi_base
2B. Split the in-memory part of a patch as a separate
3. Construct some variants for leaving "double xmax" format as a temporary one just after upgrade for having only one persistent on-disk format instead of two.
3A. By using SQL function "vacuum doublexmax;"
OR
3B. By freeing space on all heap pages for pd_special before pg-upgrade.
OR
3C. By automatically repacking all "double xmax" pages after upgrade (with a priority specified by common vacuum-related GUCs)
4. Intentionally prohibit starting a new transaction with XID difference of more than 2^32 from the oldest currently running one. This is to enforce some dba's action for cleaning defunct transaction but not binding one: he/she can wait if they consider these old transactions not defunct.
5. Investigate and add a solution for archs without 64-bit atomic values.
5A. Provide XID 8-byte alignment for systems where 64-bit atomics is provided for 8-byte aligned values.
5B. Wrap XID reading into PG atomic locks for remaining 32-bit ones (they are expected to be rare).