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

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
Дата
Msg-id CAHGQGwGGpoKHf8eov5MKwfC7cnr1gmU0-+ZxxXB9bX8y30xgiA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)  (Phil Sorber <phil@omniti.com>)
Ответы Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)  (Phil Sorber <phil@omniti.com>)
Список 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 по дате отправления:

Предыдущее
От: Cody Cutrer
Дата:
Сообщение: NOT VALID FKs and Constraints
Следующее
От: Robert Haas
Дата:
Сообщение: Re: logical changeset generation v4 - Heikki's thoughts about the patch state