Re: Challenges preventing us moving to 64 bit transaction id (XID)?

Looking at the patch set attached by Alexander Korotkov, a large number of
changes were required to update the code to use XID_FMT (INT64_FORMAT)
instead of %u in print format strings. I think these are infrastructural
changes would be required in any 64-bit implementation, and a separate
low-risk commit could be created to just make these changes. This patch
would touch 35 files and is already large enough to separate out by itself.
Does anyone have any objections to such a patch?

One of the other changes proposed by the patch that Alexander posted in this
thread was to refactor the special area for heaps and move pd_prune_xid from
PageHeaderData to HeapPageSpecialData; however, this conflicts with a later
commit, 52ac6cd2d0c, by Andrey Borodin and Alexander Korotkov, to fix a
locking problem with gin indexes:

"Due to binary compatibility we can't change GinPageOpaqueData to store
corresponding transaction id. Instead we reuse page header pd_prune_xid
field, which is unused in index pages."

In other words, prior to the time the 64bit XID patch was written the
pd_prune_xid was in the page header but was unused for index pages, but as
of commit 52ac6cd2d0c, pd_prune_xid became used by gin indexes, so moving it
out of the page header to the heap special data area doesn't work for gin
any more.

If GinPageOpaqueData can't be modified for the reason stated above, then a
different solution would be required for the 64bit XID patch. pd_prune_xid
is still used in the 64bit XID patch, so I don't think the refactoring saves
any space on a heap page, though it may save 32 bits per page on non-gin
index pages.

What would the downside(s) be, if any, of leaving pd_prune_xid in the header
in the 64bit patch?

-----
Jim Finnerty, AWS, Amazon Aurora PostgreSQL
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html