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.
