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
