Re: windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED
От | Thomas Munro |
---|---|
Тема | Re: windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED |
Дата | |
Msg-id | CA+hUKGLh_fD3Bu59zR6P9KYsnUh5jShA=xUQB6MzdBA7V3d-=A@mail.gmail.com обсуждение исходный текст |
Ответ на | windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED
|
Список | pgsql-hackers |
On Wed, Feb 8, 2023 at 2:28 PM Andres Freund <andres@anarazel.de> wrote: > 2023-02-08 00:53:20.257 GMT client backend[4584] pg_regress/rangetypes STATEMENT: select '-[a,z)'::textrange; > TRAP: failed Assert("PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED"), File: "../src/backend/storage/ipc/pmsignal.c",Line: 329, PID: 5948 No idea what's going on yet, but this assertion failure is very familiar to me, as one of the ways that lorikeet fails/failed (though it hasn't failed like that since the postmaster latchification). There it was because Cygwin's signal blocking is unreliable, so the postmaster could start a backend, while already being in the middle of starting a backend. That particular problem shouldn't be possible anymore; now we can only start backends from inside the main event loop. Hmm. (State machine bug? Some confusion about processes caused by the fact that PID was recycled?)
В списке pgsql-hackers по дате отправления: