Bruce Momjian <br...@momjian.us> writes:
> Tom Lane wrote:
>> Possibly the cleanest fix is to implement pg_ping as a libpq function.
>> You do have to distinguish connection failures (ie connection refused)
>> from errors that came back from the postmaster, and the easiest place to
>> be doing that is inside libpq.
> OK, so a new libpq function --- got it. Would we just pass the status
> from the backend or can it be done without backend modifications?
It would definitely be better to do it without backend mods, so that
the functionality would work against back-branch postmasters.
To my mind, the entire purpose of such a function is to classify the
possible errors so that the caller doesn't have to. So I wouldn't
consider that it ought to "pass back the status from the backend".
I think what we basically want is a function that takes a conninfo
string (or one of the variants of that) and returns an enum defined
more or less like this:
* failed to connect to postmaster
* connected, but postmaster is not accepting sessions
* postmaster is up and accepting sessions
I'm not sure those are exactly the categories we want, but something
close to that. In particular, I don't know if there's any value in
subdividing the "not accepting sessions" status --- pg_ctl doesn't
really care, but other use-cases might want to tell the difference
between the various canAcceptConnections failure states.
BTW, it is annoying that we can't definitively distinguish "postmaster
is not running" from a connectivity problem, but I can't see a way
around that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
