>> Nope, we need to pass the handle. Only one process can be the
>> server-side of the pipe, and once the postmaster has opened it, the
>> child process can't do it - the only way to get it is through
>> inheritance.
>
>Grumble. Having to call write_backend_variables from two different
>places seems Really Ugly.
Well, if they're separated by
#ifdef win32
first one
#else
second one
#endif
that's slightly less Ugly. Still Ugly, just maybe not Really Ugly.
The actual code-duplication is only 2-3 statements + three asserts, so
it's not *that* bad. The rest of internal_forkexec() is already
#ifdef-split between win32 and non-win32.
>How about Plan B? It occurs to me that what this proposal really does
>is to delay the postmaster until after the child process has been
>created. What about doing that in some more straightforward fashion
>--- that is, the postmaster doesn't return from win32_forkexec until
>it sees that the child has gotten at least as far as being able to
>accept signals? (A simple way to do it would just be to loop trying to
>kill(0) the child PID.) I guess the tricky part here is recovering if
>the child fails to start at all --- a timeout would perhaps do but it's
>ugly. Still, seems less ugly than the way this idea is panning out.
I actually think this one is more ugly :-( It also makes the postmaster
stop what it's doing for a while during the backend startup. With lots
of backend starts, that might become noticeable.
I was also hoping to piggyback the socket fix on top of this
infrastructure. And that *requires* the write-files-after-createprocess
method. There is no other way. Doing it this way means we either give up
on the socket fix completely, or that we do it *both* ways, which seems
like the worst of both worlds.
(If you forgot, this is the bug that has us saying "uninstall your
antivirus and firewall software", which is generally not such brilliant
advice on windows)
//Magnus
