[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    [GENERAL] How to wait until startup completes
From:       Gary Horton <Gary.Horton () Sun ! COM>
Date:       2005-05-31 22:01:32
Message-ID: 429CDEBC.4080404 () sun ! com
[Download RAW message or body]

I'm starting up postgresql with this command line:

/usr/bin/setpgrp ${POSTGRESQL_HOME}/bin/pg_ctl -w -o "-i" start

...and there are two things about this that raise a question. First, we 
use the setpgrp because, although pg_ctl documentation (7.3.4) states 
that it can be used for  "properly detaching from the terminal and 
process group", we have not found this to work as expected. In 
particular, when a ctl-C is issued from the same tty as was used for the 
pg_ctl command (without the setpgrp), the associated postmaster 
processes are killed (with a fast shutdown, i.e. they receive the SIGINT 
signal from the ctl-C). Prefacing pg_ctl with setpgrp addresses this 
problem for us. So, the first question would be, what am I not 
understanding here?

More importantly, we want to start up the database "completely" before 
any client connections are attempted. This matters to us in our 
build/test environment where we have complete control over client 
connections; we're only trying to be certain the database is ready 
before launching a series of builds/tests that don't initialize properly 
due to the "FATAL: The database system is starting up" messages, which 
are received on each attempted client connection, and wasting a whole 
build-test cycle as a result. According the pg_ctl documentation again, 
we're told that the -w flag will cause pg_ctl to "Wait for the start or 
shutdown to complete", and we hoped this would effectively cause pg_ctl 
to block until the database startup is "complete"; however this too does 
not work as expected. We are testing for "startup-is-complete" with the 
following:

until ${POSTGRESQL_HOME}/bin/psql -l > /dev/null 2>&1 || 
${POSTGRESQL_HOME}/bin/psql -l -d template1 -U $PORTAL_DB_OWNER

...and it happens that /sometimes/ this test succeeds and yet subsequent 
client connections fail due to the "FATAL: The database system is 
starting up" condition.

 From this, a whole series of questions comes up in my mind:

- is this the proper idiom to test for database startup being "complete" 
(i.e. "complete" means that the "FATAL: The database system is starting 
up" error messages should not occur)?
- If not, what test should we be using instead?
- If so, what could be happening here?
- is there a better way to start up postresql to achieve what we want?
- is setpgrp somehow getting in the way of the -w flag working as desired?

Thanks for any insights -
Gary Horton


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq
[prev in list] [next in list] [prev in thread] [next in thread]