Re: Add 64-bit XIDs into PostgreSQL 15

Hello, hackers!

Unfortunately, the problem of inconsistency while using prune_frezze
with repairFragmentation=false does not only pertain to the content of
dead and unused tuples, but it also can bring about inconsistency of
locations of alive tuples.

This case appears in the logic of heap_insert. See the attached figure.
When heap_insert determines that a new tuple is the only one on a page,
it sets the XLOG_HEAP_INIT_PAGE and, as a result, “redo”-side
initializes the new page and inserts the new tuple on this new page
instead of inserting the new tuple on the existing page.

So, we have the next situation in the xid64 patch.

Do-side:
1. Having page ABC with several tuples.
2. Starting to perform insertion of new tuple
2.1. In the case of an inappropriate xid_base, trying to fit base
2.1.1 Freezing and pruning tuples without further repairing
fragmentation.
2.1.2 All tuples have been pruned (no alive tuples on the page
since this moment)
3. Inserting a new tuple and setting XLOG_HEAP_INIT_PAGE, assuming that
the only tuple located at the bottom of the page (assuming that
fragmentation has been performed).

Result: We have the ABC page with the new tuple inserted somewhere in
the MIDDLE of the page and surrounded with garbage from dead and unused
tuples. At the same time we have an xlog record bringing the
XLOG_HEAP_INIT_PAGE bit.

Redo-side
1. Observing XLOG_HEAP_INIT_PAGE
2. Creating a new page and inserting the new tuple into the first
position of the page.

Result: We have the ABC page with the new tuple inserted at the BOTTOM
of the page.

This example of inconsistency is not about the content of the tuple but
about tuple’s locations on the page. And tuple offsets are not subject
to masking by the standard masking procedure.

The possible fix can be like one in attachment. But what I’m trying to
suggest is adhering to the original realization of PG, performing
prune_freeze only under a buffer cleanup lock, and fully excluding
repairFragmentation=false as a vice!

Best regards,
Evgeny Voropaev,
Tantor Labs, LLC.