Tom Lane wrote:
> Bruce Momjian <bruce@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.
Agreed. I will research this.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +