Horton

Re: Add 64-bit XIDs into PostgreSQL 15

Evgeny Voropaev <evgeny.voropaev@tantorlabs.com>

View thread
From: Evgeny Voropaev <evgeny.voropaev@tantorlabs.com>
To: Yura Sokolov <y.sokolov@postgrespro.ru>, "Maksim.Melnikov" <m.melnikov@postgrespro.ru>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-08-05T07:04:22Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add SLRU tests for 64-bit page case

  2. Make use FullTransactionId in 2PC filenames

  3. Use larger segment file names for pg_notify

  4. Index SLRUs by 64-bit integers rather than by 32-bit integers

Attachments

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.