[PATCH] pg_isready (was: [WIP] pg_ping utility)

Changing up the subject line because this is no longer a work in
progress nor is it pg_ping anymore.

On Sun, Jan 20, 2013 at 10:36 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 01/21/2013 11:26 AM, Robert Haas wrote:
>> On Sun, Jan 20, 2013 at 2:59 PM, Phil Sorber <phil@omniti.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.
>>

I added the code comments, but realized it was already in the docs. I
will provide a separate patch for the PQping docs.

I also added the handling of extra params as Robert suggested.

>>>> 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.
>

As stated above this is no longer called pg_ping. Probably should have
switched the subject line a while ago.

I've left it outputting the host and port as default.

Also, we went over a lot of iterations on how the errors should look.
I am hesitant to change that now. I think the current errors are good
because not being able to connect isn't necessarily an unexpected
outcome like it is for psql.

> $ 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
>