Re: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Paul Kim <mok03127(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Subject: Re: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum
Date: 2026-07-20 07:16:02
Message-ID: al3LFmvcsdBF_Gqn@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 19, 2026 at 11:27:54PM +0900, Paul Kim wrote:
> ginVacuumPostingTreeLeaves() sweeps the leaf pages of a GIN posting tree
> via their rightlinks, but that loop has no vacuum_delay_point() (and hence
> no CHECK_FOR_INTERRUPTS()), unlike the sibling loops in ginbulkdelete() and
> ginvacuumcleanup().
>
> The call used to be there: it was dropped when fd83c83d094 rewrote this
> cleanup from a recursive walk into the current iterative sweep, and never
> re-added to the new loop. That commit was only about fixing a deadlock, so
> the removal looks inadvertent.

Hmm, yeah, that looks like an oversight. We have been calling
vacuum_delay_point() for each page cleaned up.

> The attached patch restores the call, placed where the buffer has already
> been released so no content lock is held across the delay. It is against
> master; on branches before 18 vacuum_delay_point() takes no argument (the
> is_analyze parameter was added by e5b0b0ce150), so the back-branch version
> is just "vacuum_delay_point();".

This suggested location looks sensible as well, after unlocking a
buffer that has been cleaned up, before taking a lock on the next one.

Looking at the thread of fd83c83d0943 at [1], the first patch has
worked on the problem differently, while the first version of the
patch that has led to the commit does not mention a reason why
vacuum_delay_point() should be removed, so I think that it's simply an
oversight.

Adding Alexander Korotkov in CC, as the original committer of
fd83c83d0943.

[1]: https://www.postgresql.org/message-id/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nisha Moond 2026-07-20 07:21:28 Re: Support EXCEPT for TABLES IN SCHEMA publications
Previous Message Chao Li 2026-07-20 06:59:51 Re: Fix RLS checks for UPDATE/DELETE FOR PORTION OF leftover rows