| 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
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | shveta malik | 2026-07-22 03:39:02 | Re: sequencesync worker race with REFRESH SEQUENCES |