Re: Startup process deadlock: WaitForProcSignalBarriers vs aux process
| От | Alexander Lakhin |
|---|---|
| Тема | Re: Startup process deadlock: WaitForProcSignalBarriers vs aux process |
| Дата | |
| Msg-id | 2a199ba7-1d18-438a-847e-5241b7dac514@gmail.com обсуждение |
| Ответ на | Re: Startup process deadlock: WaitForProcSignalBarriers vs aux process (Masahiko Sawada <sawada.mshk@gmail.com>) |
| Ответы |
Re: Startup process deadlock: WaitForProcSignalBarriers vs aux process
|
| Список | pgsql-hackers |
Dear Sawada-san, 28.04.2026 22:27, Masahiko Sawada wrote: > On Mon, Apr 27, 2026 at 11:00 AM Alexander Lakhin <exclusion@gmail.com> wrote: >> I've been puzzled by a buildfarm failure [1] with such symptoms for a while >> and even reproduced it locally once, but couldn't gather more information >> that time. But now that you have described the scenario, I can easily >> reproduce the same test failure with: >> --- a/src/backend/storage/ipc/procsignal.c >> +++ b/src/backend/storage/ipc/procsignal.c >> @@ -206,6 +206,7 @@ ProcSignalInit(const uint8 *cancel_key, int cancel_key_len) >> if (cancel_key_len > 0) >> memcpy(slot->pss_cancel_key, cancel_key, cancel_key_len); >> slot->pss_cancel_key_len = cancel_key_len; >> +pg_usleep(10000); >> pg_atomic_write_u32(&slot->pss_pid, MyProcPid); > Thank you for testing this. > > I've attached a patch to address the issue. I haven't verified it > across all versions yet, but I suspect it exists in the stable > branches as well... Thank you for the fix! It works for me too. I was wondering why is that failure the only one of this kind on buildfarm (in last two years, at least), so I've tried to reproduce it on REL_18_STABLE... and failed. Then I've bisected it on the master branch and found (your) commit that introduced this behavior: 67c20979c from 2025-12-23. Best regards, Alexander
В списке pgsql-hackers по дате отправления: