From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Phil Sorber <phil(at)omniti(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] pg_isready (was: [WIP] pg_ping utility) |
Date: | 2013-01-23 23:07:51 |
Message-ID: | 28803.1358982471@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Phil Sorber <phil(at)omniti(dot)com> writes:
> On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-01-23 23:14:39 | Re: [COMMITTERS] pgsql: Improve concurrency of foreign key locking |
Previous Message | MauMau | 2013-01-23 22:42:45 | Re: Back-branch update releases coming in a couple weeks |