| 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
| 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 |