21.07.2025 12:28, Daniil Davydov пишет: > Hi, > > On Thu, Jul 17, 2025 at 8:36 PM Maksim.Melnikov > <m.melni...@postgrespro.ru> wrote: >> >> 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. >> >> 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. >> > > I have also tried to reproduce this bug. To do this, we need several > conditions: > 1) New tuple must be "linked" with the first line pointer on page
This is not quite right. Empty space large enough for new tuple may lead page to be selected for insertion. Yet it have to pass "prunning" on page read-access path. So either empty space need to be even larger (to not trigger prunning), or there should be tuple interested for transaction alive at the moment of page read-access, but finished at the moment of heap_insert execution. It looks to be quite complex condition, so it should be extremely rare in production. But still possible. More over, it is hard for the bug to trigger real problems, because INSERT/UPDATE/DELETE uses tuple numbers to describe operation, not offsets. So operations are executed correctly... unless there were switch of master, and replica did more insertions into same page, so it overflowed free space on previous master, and full page write were disabled. So, the bug is real. But looks like it is quite minor. (Disclaimer: I didn't analyze code again to write text above, so I could be mistaken somewhere). -- regards Yura Sokolov aka funny-falcon
