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.
From 650a90692a6f601057be145c7d62474462de32db Mon Sep 17 00:00:00 2001
From: Evgeny Voropaev <evo...@gmail.com>
Date: Tue, 5 Aug 2025 14:18:37 +0800
Subject: [PATCH] Emulating page inconsistency at a WAL-redo-Heap/INSERT+INIT
operation.
Replaying problem.
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
```
---
src/backend/access/heap/pruneheap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/access/heap/pruneheap.c b/src/backend/access/heap/pruneheap.c
index fc8e14a9f25..b6e8771f74b 100644
--- a/src/backend/access/heap/pruneheap.c
+++ b/src/backend/access/heap/pruneheap.c
@@ -265,7 +265,7 @@ heap_page_prune_opt(Relation relation, Buffer buffer)
* that during on-access pruning with the current implementation.
*/
heap_page_prune_and_freeze(relation, buffer, vistest, 0,
- NULL, &presult, PRUNE_ON_ACCESS, &dummy_off_loc, NULL, NULL, true);
+ NULL, &presult, PRUNE_ON_ACCESS, &dummy_off_loc, NULL, NULL, false);
/*
* Report the number of tuples reclaimed to pgstats. This is
--
2.49.0
