Re: Add 64-bit XIDs into PostgreSQL 15

Hello hackers!

I still have not created a TAP-test allowing for narrowing the problem 
of page inconsistency with a WAL-redo-Heap/INSERT+INIT operation. But 
the next script allows us to replay the problem during more common and 
more general tests.

1. Do not apply a fix for this problem or use the xid64 patch of the v64 
version or less.

2. Use the `Emulating page inconsistency at a WAL-redo-Heap/INSERT+INIT 
operation` patch, which implements `repairFragmentation=false` at the 
invocation of `heap_page_prune_and_freeze` from the 
`heap_page_prune_opt` function.
It is quite contrived code, but it allows for replaying the problem.

3. Start the 027_stream_regress.pl test with the next command:
   make -C "./src/test/recovery/" check 
PROVE_TESTS="t/027_stream_regress.pl" 
PG_TEST_EXTRA="wal_consistency_checking"

As a result, you should see
```
2025-08-05 14:15:38.196 +08 startup[173535] FATAL:  inconsistent page 
found, rel 1663/16384/1259, forknum 0, blkno 0
2025-08-05 14:15:38.196 +08 startup[173535] CONTEXT:  WAL redo at 
0/3490EF0 for Heap/INSERT+INIT: off: 0, flags: 0x00; blkref #0: rel 
1663/16384/1259, blk 0 FPW
```

I am convinced that a sequence is next:
Step 1. Something (in the case of a presented contrived code, it is the 
`heap_page_prune_opt` function) prunes the page with 
repairFragmentation=false, kills all tuples and does not repair 
fragmentation of the pruned page.
Step 2. Inserting is performed to this empty, but not repaired page.
Result. The problem of page inconsistency at a WAL-redo-Heap/INSERT+INIT 
operation.

In this scenario we do not even need to invoke `prepare_page_for_xid` or 
`freeze_single_heap_page`.

Once again, it is quite contrived code, and I do not know if it is 
possible that the real xid64-patch code once will perform pruning with 
repairFragmentation=false, and subsequently will perform 
Heap/INSERT+INIT. But maybe this contrived code will help us to replay 
the problem and to create specific TAP-test.

Best regards,
Evgeny Voropaev.