Tom Lane wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Wed, Nov 17, 2010 at 19:57, Bruce Momjian <br...@momjian.us> wrote: > >> Is FATAL, in general, enough to conclude the server is running? > > > No - specifically, we will send FATAL when "the database system is > > starting up", which is exactly the one we want to *avoid*. > > > I think we should only exclude the password case. I guess we could > > also do all fatal *except* <list>, but that seems more fragile. > > I believe that the above argument is exactly backwards. What we want > here is to check the result of postmaster.c's canAcceptConnections(), > and there are only a finite number of error codes that can result from > rejections there. If we get past that, there are a large number of > possible failures, but all of them indicate that the postmaster is in > principle willing to accept connections. Checking for password errors > only is utterly wrong: any other type of auth failure would be the same > for this purpose, as would "no such database", "no such user", "too many > connections", etc etc etc.
Agreed. So how do we pass that info to libpq without exceeding the value of fixing this problem? Should we parse pg_controldata output? pg_upgrade could use machine-readable output from that too. > What we actually want here, and don't have, is the fabled pg_ping > protocol... Well, we are basically figuring how to implement that with this fix, whether it is part of pg_ctl or a separate binary. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers