On 2019-07-17 20:51, Tom Lane wrote:
r.zhar...@postgrespro.ru writes:
pg_ctl now opens the postmaster.pid file using pgwin32_open() function
to correctly handle share locks.
HEAD already does that, no? See f02259fe9.
You are right. I tested branch REL_11_STABLE and it is my mistake.
On Windows systems we cannot handle ERROR_DELETE_PENDING because
GetLastError() returns ERROR_ACCESS_DENIED instead.
So we rename the lock files before delete them.
This seems improbably broken/stupid. Also, I've not seen any buildfarm
failures that would match this; it's always pg_ctl complaining not the
postmaster.
The probability is very small. In one of our tests pg_ctl fails with
that error sometime.
In a test with multiple frequent restarts the probability is 5-6%. On
other machines probability differs.
To find out the real error code we used the Process Monitor utility.
To avoid the second error we added the wait for cmd.exe finish in the
do_stop() and do_restart() functions.
Hmmm ... there seems the germ of a good idea here, but can't we do
it with less (and less ugly) code?
Alternatively, perhaps we could fix things so that the parent cmd.exe
shell isn't involved in logfile access? That'd require teaching the
postmaster to open/redirect its stdout/stderr, which is kind of
annoying, but it might beat hacking things as you have done here.
If we need parent cmd.exe only for log writing, can we start the
postmaster without it?
Is cmd.exe necessary?
--
regards, Roman Zharkov
