On Sun, 2010-03-28 at 12:47 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Fri, 2010-03-26 at 18:59 +0000, Greg Stark wrote:
> >> It occurs to me we could do the same for CHECK_FOR_INTERRUPTS() by
> >> conditionally having it call a function which calls gettimeofday and
> >> compares with the previous timestamp received at the last CFI().
>
> > Reducing latency sounds good, but what has CFI got to do with that?
>
> It took me about five minutes to figure out what Greg was on about too.
> His point is that we need to locate code paths in which an extremely
> long time can pass between successive CFI calls, because that means
> the backend will fail to respond to SIGINT/SIGTERM for a long time.
> Instrumenting CFI itself is a possible tool for that.
I was thinking we could do this via signals, but actually instrumenting
the code paths seems better.
There probably are a few paths still to improve. Dare I suggest we
follow the tried and tested open source approach of wait-for-complaint?
Reducing latency elsewhere would be time better spent (!). I was
thinking of adding a "reason" field onto ReadBuffer, so we can diagnose
the source of buffer waits.
-- Simon Riggs www.2ndQuadrant.com