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

From Andrew Dunstan
Subject Re: We should Axe /contrib/start-scripts
Date
Msg-id 4A943F97.90809@dunslane.net
Whole thread Raw
In response to Re: We should Axe /contrib/start-scripts  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: We should Axe /contrib/start-scripts
List pgsql-hackers

Kevin Grittner wrote:
> Tom Lane <tgl@sss.pgh.pa.us> wrote: 
>  
>   
>> Hmm.  As stated, I would expect pg_ctl to make it worse.
>>     
>  
> I've been playing with this, and I think the problem was that we
> wanted a non-zero exit from the script if the start failed.  That's
> trivial with pg_ctl -w but not running postgres directly.  I guess I
> could run pg_ctl status in a loop after the start.
>  
> The reason is that we don't want certain other processes attempting to
> start until and unless the database they use has started successfully.
>   


Have you looked at what the Fedora script does?

Here's a snippet from my F11 system:
       $SU -l postgres -c "$PGENGINE/postmaster -p '$PGPORT' -D 
'$PGDATA' ${PGOPTS} &" >> "$PGLOG" 2>&1 < /dev/null       sleep 2       pid=`pidof -s "$PGENGINE/postmaster"`       if
[$pid ] && [ -f "$PGDATA/postmaster.pid" ]       then               success "$PSQL_START"               touch
/var/lock/subsys/${NAME}              head -n 1 "$PGDATA/postmaster.pid" > 
 
"/var/run/postmaster.${PGPORT}.pid"               echo       else               failure "$PSQL_START"
echo              script_result=1       fi
 


Doesn't seem that much harder than using pg_ctl.

cheers

andrew


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: We should Axe /contrib/start-scripts
Next
From: Alvaro Herrera
Date:
Subject: Re: We should Axe /contrib/start-scripts