Tom Lane wrote:
> Bruce Momjian <[email protected]> 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 <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
