How to tell when postmaster is ready

[Thomas Hallgren]

I'm writing a small test harness. I have two threads. One that starts
the postmaster and another that does all the testing and finally stops
the postmaster with a pg_ctl stop. At present, the second thread starts
with a sleep sufficient to ensure that the postmaster is running. Is
there a proper way to test when the postmaster is ready to receive commands?

Kind regards,

Thomas Hallgren

[Holger Klawitter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 10 June 2004 09:10, Thomas Hallgren wrote:

I'm writing a small test harness. I have two threads. One that starts
the postmaster and another that does all the testing and finally stops
the postmaster with a pg_ctl stop. At present, the second thread starts
with a sleep sufficient to ensure that the postmaster is running. Is
there a proper way to test when the postmaster is ready to receive
commands?

postmaster will not send a signal on its own,
but you can do some kind of busy polling:

# untested bash script
count=0
while true
do
if psql -c '\q' $MY_DATABASE 2>/dev/null
then
break
fi
count=$(($count + 1))
if [ $count > 10 ]
then
echo "Postgres seems not to be working" >&2
exit 1
fi
sleep 1
done
psql $MY_DATABASE

Mit freundlichem Gruß / With kind regards
Holger Klawitter
- --
lists <at> klawitter <dot> de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAyBlE1Xdt0HKSwgYRAtoKAJ9uWwaSQPyFae+q7bZFP6 ovDRcTgwCcD2Dl
FdpLC9FtMsZ7PZtGqfW843g=
=BHoK
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Holger Klawitter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 10 June 2004 09:10, Thomas Hallgren wrote:

I'm writing a small test harness. I have two threads. One that starts
the postmaster and another that does all the testing and finally stops
the postmaster with a pg_ctl stop. At present, the second thread starts
with a sleep sufficient to ensure that the postmaster is running. Is
there a proper way to test when the postmaster is ready to receive
commands?

postmaster will not send a signal on its own,
but you can do some kind of busy polling:

# untested bash script
count=0
while true
do
if psql -c '\q' $MY_DATABASE 2>/dev/null
then
break
fi
count=$(($count + 1))
if [ $count > 10 ]
then
echo "Postgres seems not to be working" >&2
exit 1
fi
sleep 1
done
psql $MY_DATABASE

Mit freundlichem Gruß / With kind regards
Holger Klawitter
- --
lists <at> klawitter <dot> de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAyBlE1Xdt0HKSwgYRAtoKAJ9uWwaSQPyFae+q7bZFP6 ovDRcTgwCcD2Dl
FdpLC9FtMsZ7PZtGqfW843g=
=BHoK
-----END PGP SIGNATURE-----
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

[Richard Huxton]

Thomas Hallgren wrote:

I'm writing a small test harness. I have two threads. One that starts
the postmaster and another that does all the testing and finally stops
the postmaster with a pg_ctl stop. At present, the second thread starts
with a sleep sufficient to ensure that the postmaster is running. Is
there a proper way to test when the postmaster is ready to receive
commands?

I've always assumed once I can connect, then I can send queries. There's
certainly a "postmaster still starting up" error message I've seen,
which would support that view.

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Richard Huxton]

Thomas Hallgren wrote:

I'm writing a small test harness. I have two threads. One that starts
the postmaster and another that does all the testing and finally stops
the postmaster with a pg_ctl stop. At present, the second thread starts
with a sleep sufficient to ensure that the postmaster is running. Is
there a proper way to test when the postmaster is ready to receive
commands?

I've always assumed once I can connect, then I can send queries. There's
certainly a "postmaster still starting up" error message I've seen,
which would support that view.

--
Richard Huxton
Archonet Ltd

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Tom Lane]

Thomas Hallgren <th***@mailblocks.com> writes:

I'm writing a small test harness. I have two threads. One that starts
the postmaster and another that does all the testing and finally stops
the postmaster with a pg_ctl stop. At present, the second thread starts
with a sleep sufficient to ensure that the postmaster is running. Is
there a proper way to test when the postmaster is ready to receive commands?

Check to see if it answers a connection request. If you look in the
archives for discussion of a "pg_ping" utility you'll find more about
this. My recollection is that we'd tweaked the postmaster's behavior
so that a useful pg_ping could be written (in particular, that you'd
not need to know a valid database/user name to check for postmaster
ready), but then no one got round to actually writing it.

Now that pg_ctl is in C, it would likely make sense to rewrite its
postmaster probing as per the pg_ping ideas instead of trying to open
a normal connection.

(As for your test harness, though, you could just use pg_ctl start
with the wait option, and wait for it to finish...)

regards, tom lane

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

http://www.postgresql.org/docs/faqs/FAQ.html

[Tom Lane]

Thomas Hallgren <th***@mailblocks.com> writes:

I'm writing a small test harness. I have two threads. One that starts
the postmaster and another that does all the testing and finally stops
the postmaster with a pg_ctl stop. At present, the second thread starts
with a sleep sufficient to ensure that the postmaster is running. Is
there a proper way to test when the postmaster is ready to receive commands?

Check to see if it answers a connection request. If you look in the
archives for discussion of a "pg_ping" utility you'll find more about
this. My recollection is that we'd tweaked the postmaster's behavior
so that a useful pg_ping could be written (in particular, that you'd
not need to know a valid database/user name to check for postmaster
ready), but then no one got round to actually writing it.

Now that pg_ctl is in C, it would likely make sense to rewrite its
postmaster probing as per the pg_ping ideas instead of trying to open
a normal connection.

(As for your test harness, though, you could just use pg_ctl start
with the wait option, and wait for it to finish...)

regards, tom lane

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

http://www.postgresql.org/docs/faqs/FAQ.html

[Thomas Hallgren]

Tom Lane wrote:

Thomas Hallgren <th***@mailblocks.com> writes:

I'm writing a small test harness. I have two threads. One that starts
the postmaster and another that does all the testing and finally stops
the postmaster with a pg_ctl stop. At present, the second thread starts
with a sleep sufficient to ensure that the postmaster is running. Is
there a proper way to test when the postmaster is ready to receive commands?

Check to see if it answers a connection request. If you look in the
archives for discussion of a "pg_ping" utility you'll find more about
this. My recollection is that we'd tweaked the postmaster's behavior
so that a useful pg_ping could be written (in particular, that you'd
not need to know a valid database/user name to check for postmaster
ready), but then no one got round to actually writing it.

Now that pg_ctl is in C, it would likely make sense to rewrite its
postmaster probing as per the pg_ping ideas instead of trying to open
a normal connection.

(As for your test harness, though, you could just use pg_ctl start
with the wait option, and wait for it to finish...)

regards, tom lane

Thanks (to all who replied). I think have what I need to make good progress.

(I did try using pg_ctl start but I encountered several problems on
win32 when attempting to pass -c options to the postmaster. Seems to be
some problem concerning who parses what, the shell or pg_ctl (windows is
utterly stupid when it comes to command line parsing). And using the
wait option seemed to wait forever on win32. I'm still investigating,
will get back to you if I find something relevant).

Kind regards,

Thomas Hallgren

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Thomas Hallgren]

Tom Lane wrote:

Thomas Hallgren <th***@mailblocks.com> writes:

I'm writing a small test harness. I have two threads. One that starts
the postmaster and another that does all the testing and finally stops
the postmaster with a pg_ctl stop. At present, the second thread starts
with a sleep sufficient to ensure that the postmaster is running. Is
there a proper way to test when the postmaster is ready to receive commands?

Check to see if it answers a connection request. If you look in the
archives for discussion of a "pg_ping" utility you'll find more about
this. My recollection is that we'd tweaked the postmaster's behavior
so that a useful pg_ping could be written (in particular, that you'd
not need to know a valid database/user name to check for postmaster
ready), but then no one got round to actually writing it.

Now that pg_ctl is in C, it would likely make sense to rewrite its
postmaster probing as per the pg_ping ideas instead of trying to open
a normal connection.

(As for your test harness, though, you could just use pg_ctl start
with the wait option, and wait for it to finish...)

regards, tom lane

Thanks (to all who replied). I think have what I need to make good progress.

(I did try using pg_ctl start but I encountered several problems on
win32 when attempting to pass -c options to the postmaster. Seems to be
some problem concerning who parses what, the shell or pg_ctl (windows is
utterly stupid when it comes to command line parsing). And using the
wait option seemed to wait forever on win32. I'm still investigating,
will get back to you if I find something relevant).

Kind regards,

Thomas Hallgren

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match