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

Alexander Law <exclusion(at)gmail(dot)com> writes:
> 07.12.2019 19:54 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
>> 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?

> 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.

If it takes that much code to handle redirection on Windows, then
I agree we don't really want to do it :-(.

Your solution is a little bit messy but it seems expedient. I feel
that it doesn't really fix the problem, if we define the problem as
"somebody opened the postmaster logfile with non-sharing-friendly
parameters". This patch works around that for the specific case of
a series of pg_ctl start commands with identical -l arguments, but
the file's still not really sharable. Still, maybe that's good
enough. For our own purposes in buildfarm testing, the main residual
problem is that we can't safely inspect the postmaster logfile
immediately after pg_ctl stop; but there's a separate proposal to
fix that by hacking slurp_file.

It seems like it'd be cleaner to fix both of these things at once
by opening the logfile ourselves (rather than letting CMD.EXE do it)
and using sharing-friendly parameters at that point. But maybe it's
just not worth the trouble compared to the individual hacks.

regards, tom lane