Re: windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED
Date
Msg-id CA+hUKGLh_fD3Bu59zR6P9KYsnUh5jShA=xUQB6MzdBA7V3d-=A@mail.gmail.com
Whole thread Raw
In response to windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED  (Andres Freund <andres@anarazel.de>)
Responses Re: windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED
Next
From: "Imseih (AWS), Sami"
Date:
Subject: Re: Add index scan progress to pg_stat_progress_vacuum