Re: We should Axe /contrib/start-scripts
От | Andrew Dunstan |
---|---|
Тема | Re: We should Axe /contrib/start-scripts |
Дата | |
Msg-id | 4A943F97.90809@dunslane.net обсуждение исходный текст |
Ответ на | Re: We should Axe /contrib/start-scripts ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: We should Axe /contrib/start-scripts
|
Список | 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 по дате отправления: