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

From: Vlad Lesin <vladlesin(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Fix ProcKill lock-group vs procLatch recycle race
Date: 2026-05-28 10:02:25
Message-ID: db1f0650-7088-4e5e-bea2-b36a7dc727ba@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vlad Lesin 2026-05-28 10:22:30 Re: [PATCH] Fix ProcKill lock-group vs procLatch recycle race
Previous Message Chao Li 2026-05-28 09:26:55 Re: tablecmds: clarify recurse vs recusing