Re: [PATCH] pg_isready (was: [WIP] pg_ping utility) - Mailing list pgsql-hackers

From Phil Sorber
Subject Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
Date
Msg-id CADAkt-gO=1aPojye-K-d0XiLDHoAn84L6cP1yE-X+M_pmj8tVA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] pg_isready (was: [WIP] pg_ping utility)
List pgsql-hackers
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.

>
>                         regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Improve concurrency of foreign key locking
Next
From: Craig Ringer
Date:
Subject: Re: Visual Studio 2012 RC