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

07.12.2019 22:26 Tom Lane <tgl@sss.pgh.pa.us>:

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

I see two problems here:
1) "pg_ctl restart ... -l logfile" can fail due to timing issues
2) when it (or "pg_ctl start ... -l logfile") fails, it prints the
non-informative message:
The process cannot access the file because it
is being used by another process.
It doesn't tell the user what file is inaccessible. I think that this issue
remains unresolved for so long partly due to this unclearance. The proposed
patch fixes both, unless I miss something.

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.

Yes, even if someone would manage to lock the logfile by a separate program
or by starting another postgres cluster with the same logfile, he will get
a more meaningful message (after a timeout).

> 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.
>
As to slurp_file, maybe it's read-only nature should help to avoid the
issues with the logfile opening. I can test it next week.

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

If we couldn't find more advantages of rewriting create process (with
logfile), I would restrict changes to one hack (or two, if really needed).

Best regards,
Alexander