Re: Add vacuum_delay_point() to GiST empty-page deletion pass

From: Paul Kim <mok03127(at)gmail(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: michael(at)paquier(dot)xyz, x4mmm(at)yandex-team(dot)ru, heikki(dot)linnakangas(at)iki(dot)fi, Paul Kim <mok03127(at)gmail(dot)com>
Subject: Re: Add vacuum_delay_point() to GiST empty-page deletion pass
Date: 2026-07-22 04:15:49
Message-ID: 20260722041549.10865-1-mok03127@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message shveta malik 2026-07-22 03:39:02 Re: sequencesync worker race with REFRESH SEQUENCES