Re: We should Axe /contrib/start-scripts - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: We should Axe /contrib/start-scripts
Date
Msg-id 4A93FD50020000250002A18A@gw.wicourts.gov
Whole thread Raw
In response to Re: We should Axe /contrib/start-scripts  (Chander Ganesan <chander@otg-nc.com>)
Responses Re: We should Axe /contrib/start-scripts  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Chander Ganesan <chander@otg-nc.com> wrote: 
> Alvaro Herrera wrote:
>> Kevin Grittner wrote:
>>
>>> The reason is that we don't want certain other processes
>>> attempting to start until and unless the database they use has
>>> started successfully.
>>
>> This is something we're not quite ready on, yet.  We need some
>> mechanism that allows scripts to verify not only that postmaster
>> started, but also that it has finished recovery.  You can sort-of
>> do it by attempting a connection and checking the error message,
>> but it's ugly.  There was talk about a pg_ping utility years ago,
>> but nobody got around to writing it ...
>>
> Can't you use pg_controldata to see whether it is in recovery or
> not?  Seems like you've got a way to see if it's running, seeing if
> it is in recovery should therefore be pretty straightforward, no?
Thanks Andrew, Alvaro, and Chander.  You've given me some thoughts to
toss around.  Of course, any of these is going to be somewhat more
complex than using "set -e" and the following lines:
case $1 in start)       echo -n "Starting PostgreSQL: "       su - $PGUSER -c "$PGCTL start -w -D '$PGDATA' -l
'$PGLOG'"      echo "ok"       ;;
 
But that's OK, if it yields better results.  :-)
-Kevin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: We should Axe /contrib/start-scripts
Next
From: Tom Lane
Date:
Subject: Re: We should Axe /contrib/start-scripts