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 →
  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

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.