From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED |
Date: | 2023-03-14 00:29:56 |
Message-ID: | ZA/ABFGgPYOuXH1C@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 14, 2023 at 01:01:28PM +1300, Thomas Munro wrote:
> Ahhh. Right, of course. The handle thing makes total sense now that
> you point it out, and although I couldn't find it in the fine manual,
> a higher authority has it in black and white[1]. Even without knowing
> which of those calls is releasing the process table entry, we're doing
> all of them on the wrong side of that IOCP. Alright, here is a patch
> to schlep most of that code over into waitpid(), where it belongs.
>
> [1] https://devblogs.microsoft.com/oldnewthing/20110107-00/?p=11803
I have a small question here..
The emulation of waitpid() for WIN32 is now in postmaster.c. Could it
make sense for some of the frontend code to be able to rely on that,
as well?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-03-14 00:41:48 | Re: windows CI failing PMSignalState->PMChildFlags[slot] == PM_CHILD_ASSIGNED |
Previous Message | Tom Lane | 2023-03-14 00:26:17 | Re: ICU 54 and earlier are too dangerous |