Re: [PATCH] Fix vacuum_delay_point happening inside lock

From: "Kevin Rocker" <me(at)kevinrocker(dot)com>
To: "Andrey Borodin" <x4mmm(at)yandex-team(dot)ru>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Neil Chen" <carpenter(dot)nail(dot)cz(at)gmail(dot)com>, "pgsql-hackers mailing list" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Fix vacuum_delay_point happening inside lock
Date: 2026-08-24 02:08:50
Message-ID: f5ab0652-d1b1-4bd1-943b-da98c222624f@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Glad to hear the per-bucket logic makes sense. I reached the same conclusion: if nothing in per-page was safe, per-bucket is as close as we can get.

v6 updates the assert and rebases on 8aa49d34e977af, and full CI is clean on my fork [0].

I'll flag this in CF to be backpatched to 14, let me know if there's anything else I need to do for that or if we want to try to carve out the hash fix.

- Kevin Rocker

[0]: https://github.com/kjrocker/postgres/tree/delay-point-v6

Attachment Content-Type Size
v6-0001-Move-interrupt-checks-out-of-locked-regions.patch text/x-patch 4.5 KB
v6-0002-Assert-that-vacuum_delay_point-is-called-only-whe.patch text/x-patch 1.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Richard Guo 2026-08-24 01:53:57 Re: Wrong results from join removal with DISTINCT ON + SRF subquery