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)
|
Список | 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 по дате отправления: