Michael Paquier <michael.paqu...@gmail.com> writes:
> On Sat, Sep 26, 2015 at 9:12 AM, Tom Lane wrote:
>> So the attached modified patch adjusts the PID-match logic and some
>> comments, but is otherwise what I posted before. I believe that this
>> might actually work on Windows, but I have no way to test it. Someone
>> please try that? (Don't forget to test the service-start path, too.)
> If "pg_ctl start" is invoked directly from a command prompt, it works.
> Now, if I run "pg_ctl start" within a script (in an msysgit
> environment for example), pg_ctl fails, complaining that
> postmaster.pid already exists. The TAP tests get broken as well,
Reading that again, I think you mean that "pg_ctl start" works but you
didn't try "pg_ctl start -w" manually? Because it's "-w" that's at
issue here, and the failing test cases are using that.
After studying the test logs more carefully, I think the behavior they're
showing is consistent with the idea that postmaster_is_alive() doesn't
work on the CMD shell process. Which seems very likely now that I think
about it, because we're depending on an implementation of kill() that
is PG-specific.
So in fact this idea doesn't work :-(.
I think there is still room to salvage something without fully rewriting
the postmaster invocation logic to avoid using CMD, because it's still
true that checking whether the CMD process is still there should be as
good as checking the postmaster proper. We just can't use kill() for it.
I'd be inclined to get rid of the use of kill() on Unix as well; as Noah
mentioned upthread, if we're using fork/exec we might as well pay
attention to waitpid's results instead. On Windows, I imagine that the
thing to do is have start_postmaster() save aside the handle for the CMD
process, and then in test_postmaster_connection(), check the handle state
to see if the process is still running (I assume there's a way to do
that).
I can take care of the Unix side of that, but as before, somebody else
would need to code and test the Windows side. It's probably just a few
lines of code to add ... any volunteers?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
