Restore vacuum_delay_point() in GIN posting-tree leaf vacuum - Mailing list pgsql-hackers

From Paul Kim
Subject Restore vacuum_delay_point() in GIN posting-tree leaf vacuum
Date
Msg-id 178447127453.110.12276981925360691905@mail.gmail.com
Whole thread
Responses Re: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum
Re: Restore vacuum_delay_point() in GIN posting-tree leaf vacuum
List pgsql-hackers
Hi,

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.

A posting tree holds all TIDs for a single key, so for a common key it can
span many leaf pages.  While one such tree is being vacuumed, the operation
now ignores vacuum_cost_delay and cannot be interrupted (query cancel,
statement_timeout, or autovacuum cancellation when another backend wants a
conflicting lock) until the whole sweep finishes; a corrupted rightlink
forming a cycle turns it into an uninterruptible hang.

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();".

I left the initial leftmost-descent loop in the same function as-is, since
it mirrors the entry-tree descent in ginbulkdelete(), which likewise has no
delay point.

Thanks,
Paul

Attachment

pgsql-hackers by date:

Previous
From: Alexandre Felipe
Date:
Subject: Re: SLOPE - Planner optimizations on monotonic expressions.
Next
From: Andrew Dunstan
Date:
Subject: Re: Deprecation warnings on Rocky 10.2 with current dev branch