From: | "Maksim(dot)Melnikov" <m(dot)melnikov(at)postgrespro(dot)ru> |
---|---|
To: | Evgeny Voropaev <evgeny(dot)voropaev(at)tantorlabs(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Maxim Orlov <orlovmg(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
Subject: | Re: Add 64-bit XIDs into PostgreSQL 15 |
Date: | 2025-07-17 13:36:10 |
Message-ID: | 9682549a-3c8f-46d9-89c0-d9465401e9ea@postgrespro.ru |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
tuple-location-inconsistency-scenario-desc.txt | text/plain | 9.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2025-07-17 14:25:46 | Re: Fix lwlock.c and wait_event_names.txt discrepancy |
Previous Message | Robert Haas | 2025-07-17 13:24:02 | Re: Test instability when pg_dump orders by OID |