Alexander Law <exclusion@gmail.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:
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.
