Re: [PATCH] pg_isready (was: [WIP] pg_ping utility) - Mailing list pgsql-hackers
From | Fujii Masao |
---|---|
Subject | Re: [PATCH] pg_isready (was: [WIP] pg_ping utility) |
Date | |
Msg-id | CAHGQGwGGpoKHf8eov5MKwfC7cnr1gmU0-+ZxxXB9bX8y30xgiA@mail.gmail.com Whole thread Raw |
In response to | Re: [PATCH] pg_isready (was: [WIP] pg_ping utility) (Phil Sorber <phil@omniti.com>) |
Responses |
Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
|
List | pgsql-hackers |
On Fri, Jan 25, 2013 at 1:45 AM, Phil Sorber <phil@omniti.com> wrote: > On Wed, Jan 23, 2013 at 8:12 PM, Fujii Masao <masao.fujii@gmail.com> wrote: >> On Thu, Jan 24, 2013 at 8:47 AM, Phil Sorber <phil@omniti.com> wrote: >>> On Wed, Jan 23, 2013 at 6:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> Phil Sorber <phil@omniti.com> writes: >>>>> On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian <bruce@momjian.us> wrote: >>>>>> On Wed, Jan 23, 2013 at 12:27:45PM -0500, Tom Lane wrote: >>>>>>> +1 for default timeout --- if this isn't like "ping" where you are >>>>>>> expecting to run indefinitely, I can't see that it's a good idea for it >>>>>>> to sit very long by default, in any circumstance. >>>> >>>>>> FYI, the pg_ctl -w (wait) default is 60 seconds: >>>> >>>>> Great. That is what I came to on my own as well. Figured that might be >>>>> a sticking point, but as there is precedent, I'm happy with it. >>>> >>>> I'm not sure that's a relevant precedent at all. What that number is >>>> is the time that pg_ctl will wait around for the postmaster to start or >>>> stop before reporting a problem --- and in either case, a significant >>>> delay (multiple seconds) is not surprising, because of crash-recovery >>>> work, shutdown checkpointing, etc. For pg_isready, you'd expect to get >>>> a response more or less instantly, wouldn't you? Personally, I'd decide >>>> that pg_isready is broken if it didn't give me an answer in a couple of >>>> seconds, much less a minute. >>>> >>>> What I had in mind was a default timeout of maybe 3 or 4 seconds... >>> >>> I was thinking that if it was in a script you wouldn't care if it was >>> 60 seconds. If it was at the command line you would ^C it much >>> earlier. I think the default linux TCP connection timeout is around 20 >>> seconds. My feeling is everyone is going to have a differing opinion >>> on this, which is why I was hoping that some good precedent existed. >>> I'm fine with 3 or 4, whatever can be agreed upon. >> >> +1 with 3 or 4 secounds. >> >> Aside from this issue, I have one minor comment. ISTM you need to >> add the following line to the end of the help message. This line has >> been included in the help message of all the other client commands. >> >> Report bugs to <pgsql-bugs@postgresql.org>. > > Ok, I set the default timeout to 3 seconds, added the bugs email to > the help, and also added docs that I forgot last time. Thanks! > Also, still hoping to get some feedback on my other issues. set_pglocale_pgservice() should be called? I think that the command name (i.e., pg_isready) should be given to PQpingParams() as fallback_application_name. Otherwise, the server by default uses "unknown" as the application name of pg_isready. It's undesirable. Why isn't the following message output only when invalid option is specified? Try \"%s --help\" for more information. When the conninfo string including the hostname or port number is specified in -d option, pg_isready displays the wrong information as follows. $ pg_isready -d "port=9999" /tmp:5432 - no response Regards, -- Fujii Masao
pgsql-hackers by date: