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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
Дата
Msg-id 28803.1358982471@sss.pgh.pa.us
обсуждение исходный текст
Ответ на 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
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...
        regards, tom lane



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

Предыдущее
От: "MauMau"
Дата:
Сообщение: Re: Back-branch update releases coming in a couple weeks
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Improve concurrency of foreign key locking