On Wed, Jan 23, 2013 at 6:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Phil Sorber <p...@omniti.com> writes: >> On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian <br...@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. > > regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
