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

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
Дата
Msg-id CAHGQGwHJy27FM_oSasheL+567Ze6TzVH++fhpPCnRjGPjTAAkg@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 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>.

Regards,

-- 
Fujii Masao



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Back-branch update releases coming in a couple weeks
Следующее
От: Robert Haas
Дата:
Сообщение: Re: logical changeset generation v4 - Heikki's thoughts about the patch state