pgsql: Further improvements in pg_ctl's new wait-for-postmaster-start l - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Further improvements in pg_ctl's new wait-for-postmaster-start l
Date
Msg-id E1QRov8-0008Jd-T2@gemulon.postgresql.org
Whole thread Raw
Responses Re: pgsql: Further improvements in pg_ctl's new wait-for-postmaster-start l
List pgsql-committers
Further improvements in pg_ctl's new wait-for-postmaster-start logic.

Add a postmaster_is_alive() test to the wait loop, so that we stop waiting
if the postmaster dies without removing its pidfile.  Unfortunately this
only helps after the postmaster has created its pidfile, since until then
we don't know which PID to check.  But if it never does create the pidfile,
we can give up in a relatively short time, so this is a useful addition
in practice.  Per suggestion from Fujii Masao, though this doesn't look
very much like his patch.

In addition, improve pg_ctl's ability to cope with pre-existing pidfiles.
Such a file might or might not represent a live postmaster that is going to
block our postmaster from starting, but the previous code pre-judged the
situation and gave up waiting immediately.  Now, we will wait for up to 5
seconds to see if our postmaster overwrites such a file.  This issue
interacts with Fujii's patch because we would make the wrong conclusion
if we did the postmaster_is_alive() test with a pre-existing PID.

All of this could be improved if we rewrote start_postmaster() so that it
could report the child postmaster's PID, so that we'd know a-priori the
correct PID to test with postmaster_is_alive().  That looks like a bit too
much change for so late in the 9.1 development cycle, unfortunately.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/3c485ca8e6580409284ac50623286b0fb8cd4a57

Modified Files
--------------
src/bin/pg_ctl/pg_ctl.c |  168 +++++++++++++++++++++++++++--------------------
1 files changed, 98 insertions(+), 70 deletions(-)


pgsql-committers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: pgsql: Make decompilation of optimized CASE constructs more robust.
Next
From: Peter Eisentraut
Date:
Subject: pgsql: Some copy editing of the release notes