Re: Add 64-bit XIDs into PostgreSQL 15

Maksim.Melnikov <m.melnikov@postgrespro.ru>

From: "Maksim.Melnikov" <m.melnikov@postgrespro.ru>
To: Evgeny Voropaev <evgeny.voropaev@tantorlabs.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Andrey Borodin <x4mmm@yandex-team.ru>, Maxim Orlov <orlovmg@gmail.com>, Yura Sokolov <y.sokolov@postgrespro.ru>
Date: 2025-07-17T13:36:10Z
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

Hi all,

On 07.07.2025 11:17, Evgeny Voropaev wrote:
> Do-side:
> 1. Having page ABC with several tuples.
> 2. Starting to perform insertion of new tuple
>    2.1. In the case of an inappropriate xid_base, trying to fit base
>    2.1.1 Freezing and pruning tuples without further repairing 
> fragmentation.
>     2.1.2 All tuples have been pruned (no alive tuples on the page 
> since this moment)
> 3. Inserting a new tuple and setting XLOG_HEAP_INIT_PAGE, assuming 
> that the only tuple located at the bottom of the page (assuming that 
> fragmentation has been performed).
>
>
> Result: We have the ABC page with the new tuple inserted somewhere in 
> the MIDDLE of the page and surrounded with garbage from dead and 
> unused tuples. At the same time we have an xlog record bringing the 
> XLOG_HEAP_INIT_PAGE bit.
>
> Redo-side
> 1. Observing XLOG_HEAP_INIT_PAGE
> 2. Creating a new page and inserting the new tuple into the first 
> position of the page.


Evgeny, I've tried to reproduce described scenario, but I can't get 
XLOG_HEAP_INIT_PAGE bit set.

Short steps description.

1. create test table, insert tuple, then exec few update operations, 
then exec delete operation,
all tuples placed on one page and "select * from test_table;" return 0 
rows.
2. stop postgres and use pg_resetwal to promote xid. This will help us 
to prune tuples.
3. start postgres and insert new tuple on page, old tuples pruning 
occurs and here we expect
XLOG_HEAP_INIT_PAGE bit set in xlog rec. As I understand, it is the 
reason of further tuple location
inconsistency.
But as I see, XLOG_HEAP_INIT_PAGE bit isn't set. The reason is condition

         if (ItemPointerGetOffsetNumber(&(heaptup->t_self)) == 
FirstOffsetNumber &&
             PageGetMaxOffsetNumber(page) == FirstOffsetNumber)
         {
             info |= XLOG_HEAP_INIT_PAGE;
             bufflags |= REGBUF_WILL_INIT;
         }
As I see, new heaptup offset isn't equal to FirstOffsetNumber and it is 
quite enough to skip bit set.
I've used waldump to check bit set

rmgr: Heap        len (rec/tot):     75/    75, tx: 2147485000, lsn: 
0/02001E90, prev 0/02001E50, desc: INSERT off: 4, flags: 0x00, blkref 
#0: rel 1663/5/16431 blk 0

, so offset is 4 and desc: INSERT, in case XLOG_HEAP_INIT_PAGE is set, 
it should be INSERT+INIT.
In attached file you can find detailed test description with results, so 
you can repeat it.

Maybe I missed something in your scenario, can you please clarify?
Or maybe it is't reproducable at all.

Best regards,
Maksim Melnikov