Re: BUG #16154: pg_ctl restart with a logfile fails sometimes (on Windows)

07.12.2019 19:54 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Alexander Law <exclusion(at)gmail(dot)com> writes:
> > What is the reason for the previous shell still accessing logfile?
> > Is the reason that we don't close it before unlinking the pid file?
>
> > We can't close the logfile, as it is opened by CMD, not by the postgres
> > process. (Postmaster is started by the command "CMD.EXE /C postgres ...
> >> logfile".) So it is closed by the CMD shell after the postgres process
> > exits and the postgres can't control this (as a child process).
>
> Hmm ... so if we were talking about Unix, a reasonable solution would
> be to avoid having a separate shell process, either by telling the shell
> to "exec" the postmaster or by using fork/exec directly with no shell.
> A 99% solution would be to use "&" so that the shell doesn't wait around
> for the postmaster to die.
>
> Are any of those ideas tenable on Windows?
>
I believe that we can't implement a similar solution on Windows, as the
comment in pg_ctl says:

>
508 /*
509 * As with the Unix case, it's easiest to use the shell (CMD.EXE)
to
510 * handle redirection etc. Unfortunately CMD.EXE lacks any
equivalent of
511 * "exec", so we don't get to find out the postmaster's PID
immediately.
512 */

The possible solution is to rid of CMD and to call CreateProcess with
postgres.exe as an executable, but then we have to handle it's stdout,
stderr pipes like this:
https://docs.microsoft.com/en-us/windows/win32/procthread/creating-a-child-process-with-redirected-input-and-output
I'm afraid this would complicate things (and break an alignment with the
Unix solution), but if the uglyness of the proposed fix overweights
complexity concerns, I can try to develop an alternative patch.

Best regards,
Alexander