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 <cr...@2ndquadrant.com> wrote: > On 01/21/2013 11:26 AM, Robert Haas wrote: >> On Sun, Jan 20, 2013 at 2:59 PM, Phil Sorber <p...@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 >
pg_isready_bin_v11.diff
Description: Binary data
pg_isready_docs_v11.diff
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers