Re: [WIP] pg_ping utility

On 01/21/2013 11:26 AM, Robert Haas wrote:
> On Sun, Jan 20, 2013 at 2:59 PM, Phil Sorber <phil(at)omniti(dot)com> wrote:
>> Ok. I can add something to the notes section of the docs. I can also
>> add some code comments for this and for grabbing the default params.
> Sounds good.
>
>>> Oh, I see. Is it really important to have the host and port in the
>>> output, or should we trim that down to just e.g. "accepting
>>> connections"? It seems useful to have that if a human is looking at
>>> the output, but maybe not if a machine is looking at the output. And
>>> if somebody doesn't want it, getting rid of it with sed or awk is
>>> nontrivial - imagine:
>>>
>>> pg_isready -d "/tmp:5432 - accepting connections"
>> If you are scripting I'd assume you would use the return code value.
>> It might be reasonable to make adding the host and port the verbose
>> method and have just "accepting connections" as the default output,
>> but my concern there is a misdiagnosis because someone doesn't realize
>> what server they are connecting to. This way they can't miss it and
>> they don't have to add another command line option to get that output.
> It's a fair concern. Does anyone else have an opinion on this?
I have a strong view that the host and port *should* be printed in output.

One of the most common issues on Stack Overflow questions from new users
is with "I can't connect" problems that turn out to be them connecting
to the wrong host, port, or socket path.

It is absolutely vital that the unix socket path being used be printed
if unix socket connections are tested, as Mac OS X's insane setup means
that PostgreSQL tool builds on that platform regularly use the system
libpq not the user-installed PostgreSQL's libpq, and it defaults to a
different socket path. If users use pg_ping to verify that their
PostgreSQL instance is running it'll use the user-installed libpq -
fine, that's what we want. But the user will then wonder why the heck
Ruby on Rails's `pg' gem reports it can't connect to the unix socket.
They can't compare the unix socket paths printed in the error message if
pg_ping doesn't show it.

I would like to see pg_ping produce a similar error to psql on
connection failure.

$ psql -p 9999
psql: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.9999"?

$ psql -h localhost -p 9999
psql: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 9999?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 9999?

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services