Re: Add vacuum_delay_point() to GiST empty-page deletion pass - Mailing list pgsql-hackers

From Paul Kim
Subject Re: Add vacuum_delay_point() to GiST empty-page deletion pass
Date
Msg-id 20260722041549.10865-1-mok03127@gmail.com
Whole thread
List pgsql-hackers
On 2026-07-21, Michael Paquier wrote:
> I'd argue that this does not feel like a backpatch is strictly
> required here. It took somebody 7 years to notice the gap [...]

Thanks, Michael -- and thanks, Andrey, for confirming the oversight.

Andrey, on aligning this with the GIN thread [0]: I think GiST is
actually a bit different. The GIN one is a regression -- the call was
there until fd83c83d094 dropped it in a deadlock fix -- so to me it
reads as a back-branch matter, given that on master your proposed
rework would replace that path and carry its own vacuum_delay_point().
This GiST pass, by contrast, has never had the call since 7df159a620b
introduced the two-pass deletion in 2019, and there's no comparable
rework in flight -- so it looks like a standalone master fix rather
than a back-patch.

I don't have a strong view either way, but master-only seems the
natural fit for GiST; I'll leave the final call to you, Heikki, and
Andrey.

[0] https://postgr.es/m/178447127453.110.12276981925360691905@mail.gmail.com

--
Paul Kim



pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: sequencesync worker race with REFRESH SEQUENCES
Next
From: Japin Li
Date:
Subject: Re: Fix optind handling inconsistency in getopt_long() for missing argument