Re: Add 64-bit XIDs into PostgreSQL 15
Evgeny Voropaev <evorop.wiki@gmail.com>
From: Evgeny Voropaev <evorop.wiki@gmail.com>
To: Maxim Orlov <orlovmg@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-06-10T10:16:45Z
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 →
-
Add SLRU tests for 64-bit page case
- a60b8a58f435 17.0 landed
-
Make use FullTransactionId in 2PC filenames
- 5a1dfde8334b 17.0 landed
-
Use larger segment file names for pg_notify
- 2cdf131c46e6 17.0 landed
-
Index SLRUs by 64-bit integers rather than by 32-bit integers
- 4ed8f0913bfd 17.0 landed
Glad to see the activity around the full version of xid64!
1) About extra freezing in `freeze_single_heap_page`.
At xid64v62 `freeze_single_heap_page` performs freezing via a call to
`heap_page_prune_and_freeze`.
Why, then, does `freeze_single_heap_page` perform freezing a second time?
```
freeze_single_heap_page(Relation relation, Buffer buffer)
{
...
// First freezing
heap_page_prune_and_freeze(relation, buffer, vistest, 0, NULL, &presult,
PRUNE_ON_ACCESS, &dummy_off_loc, NULL, NULL, false);
...
// Preparation for Extra freezing
for (offnum = FirstOffsetNumber; offnum <= maxoff; offnum =
OffsetNumberNext(offnum))
{
...
heap_prepare_freeze_tuple(&tuple, &cutoffs, &pagefrz,
&frozen[nfrozen], &totally_frozen)
...
}
...
// Extra freezing
heap_freeze_prepared_tuples(relation, buffer, frozen, nfrozen);
...
}
```
Are the actions of `heap_page_prune_and_freeze` not sufficient for freezing?
If this extra freezing step is redundant, we might want to consider
removing this duplicated freezing.
2) About repairing fragmentation.
The original approach implemented in PG18 assumes that fragmentation
occurs during every `prune_freeze` operation. It happens because the
logic of the "redo"-function `heap_xlog_prune_freeze` assumes that
fragmentation has to be done by `heap_page_prune_execute`. Attempting to
omit fragmentation can result in page inconsistencies on the "redo"-side
(i.e. on a secondary node, or during the recovery process on primary
one). So, implementation of optional repairing of fragmentation
conflicts with the basic assumption about "necessity of fragmentation".
In order to prevent inconsistency xid64v62 patch invokes
`heap_page_prune_and_freeze` with `repairFragmentation` equal to true
from everywhere in the patch code except from
`heap_page_prepare_for_xid` which uses `repairFragmentation=false`.
So, why must we perform a `heap_page_prune_execute` without a
fragmentation during the preparation of a page for xid?
What exactly would break if we did perform `heap_page_prune_execute`
with NO fragmentation repair during `heap_page_prepare_for_xid`?
Best regards,
Evgeny Voropaev,
Tantor Labs, LLC.