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

Alexander Law <[email protected]>
Newsgroups gmane.comp.db.postgresql.bugs
Message-ID <CAJ0YPFEH=y0=zbUx4_8PrCn2aAWPWEf2GpAyzcTTQLuBd8HHcg@mail.gmail.com>
07.12.2019 19:54 Tom Lane <[email protected]>:

> Alexander Law <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.