Hi all, On Wed, Mar 18, 2026 at 11:12 AM Kirill Reshke <[email protected]> wrote: > > On Wed, 11 Feb 2026 at 17:18, Soumya S Murali > <[email protected]> wrote: > > > > Hi all, > > > > Thank you for the updated patch. > > I reproduced the issue locally by filling a GiST root page, deleting > > all tuples, and triggering a microvacuum by an index-only scan. > > With the patch, The root page is now handled consistently with other > > leaf pages. so->curBlkno and so->curPageLSN are properly set during > > scan, and gistkillitems() operates safely and correctly on the root > > page. > > Based on runtime validation and code inspection, the fix LGTM. > > > > > > Rebased due to f5eb854ab6d[0] > > I have added a [0]committer to CC. > > Andres, can you please take a look at this thread, if by chance you > have spare time for it? You have changed kill tuples-related logic > frequently, so you might be interested... > > [0] > https://git.postgresql.org/cgit/postgresql.git/commit/?id=f5eb854ab6d6281ec2d3143657944bdda6676341 >
I performed a follow-up test on top of the v3 patch with a strictly controlled setup to ensure a single-page GiST index (confirming that block 1 is out of range). To force the cleanup path, I executed an index-only scan after deleting all tuples and used a narrow WAL window to isolate the relevant records. The WAL output shows GiST PAGE_UPDATE on block 0, confirming that the root page is modified after the scan. However even in this setup, I do not observe any XLOG_GIST_DELETE records. This seems while the patch correctly initializes curBlkno and enables proper handling of the root page, the DELETE WAL emission depends on whether killitems actually marks tuples as DEAD under the given visible conditions. Overall, the fix looks correct from a code perspective, but in this scenario the cleanup does not result in a DELETE WAL record. Regards, Soumya
