Re: [PATCH] Fix ProcKill lock-group vs procLatch recycle race

Vlad Lesin <vladlesin@gmail.com>

From: Vlad Lesin <vladlesin@gmail.com>

To: Michael Paquier <michael@paquier.xyz>

Cc: Andrey Borodin <x4mmm@yandex-team.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2026-05-28T10:02:25Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix procLatch ownership race in ProcKill()
- 84b9d6bceab6 19 (unreleased) cited

On 5/28/26 04:08, Michael Paquier wrote:
> The test relies on a wait, but the wait mechanism in
> injection_points will not be able to work as the latch of the backends
> get detached earlier after the fix done at 84b9d6bceab6 to prevent the
> recycle race.
...
> The test was still a useful exercise to prove the bug, though.  If one
> reverts 84b9d6bceab6 and runs the test, we are able to reproduce the
> original bug.
...
> I am not sure that the
> case of this thread is good enough to justify these changes, TBH.

Yes, I agree with that arguments. Initially, I attached the test to 
prove the bug, and I mentioned my doubts about the necessity of pushing 
it in my first message. The test is supposed to fail on unfixed code, 
and then commit 84b9d6bceab6 is supposed to make it pass. After the 
simplifications proposed by Andrey, I thought that having the test even 
in its current shape is better than having no test at all, as its 
purpose is to catch regressions. The intention to have a separate module 
with proc_kill_attach_injection_wait_pid() and the other test helpers 
was driven by the wish to minimize changes to the injection point code 
and prevent the test from becoming more complex than the fix itself.

-- 
Best regards,
Vlad