Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running
Date
Msg-id 17545.1290021704@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Nov 17, 2010 at 19:57, Bruce Momjian <bruce@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.

What we actually want here, and don't have, is the fabled pg_ping
protocol...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: unlogged tables
Next
From: Kenneth Marshall
Date:
Subject: Re: unlogged tables