Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > 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.
>
> pg_controldata seems 100% unrelated to this problem. You cannot even
> tell if the postmaster is alive just by inspecting pg_control.
I was thinking of this:
$ pg_controldata /u/pg/data...Database cluster state: shut down
> >> 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.
>
> 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?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +