Re: More idle thoughts

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