Hi all, On Sun, Jul 26, 2026 at 8:09 PM Alexander Korotkov <[email protected]> wrote: > > On Mon, Jul 20, 2026 at 10:10 PM Andrey Borodin <[email protected]> wrote: > > > > > On 20 Jul 2026, at 16:59, Alexander Korotkov <[email protected]> wrote: > > > > > > We're holding cleanup lock on posting tree root while > > > ginScanPostingTreeToDelete(), not ginVacuumPostingTreeLeaves(). So, I > > > think yes, vacuum_delay_point() was deleted unintentionally. > > > > Yup, my recollection was wrong. ginVacuumPostingTreeLeaves() seems fine for > > a > > delay point. > > Please, check the patch attached. >
Thank you for the updated patch. I reviewed and tested this patch by creating a large GIN index on a table containing 10 million rows. Then deleted 9 million rows, and ran VACUUM (VERBOSE). For validation, I temporarily added instrumentation to ginVacuumPostingTreeLeaves() function. On the unpatched build, I confirmed that the posting-tree leaf traversal code was executed. Also after applying the patch, I verified that the newly added vacuum_delay_point(false) is reached and executed during the traversal of posting-tree leaf pages. I did not observe any functional regressions or unexpected behavior during testing. The patch restores the missing vacuum_delay_point() call while preserving the existing vacuum behavior. The patch looks good to me. Regards, Solai
