Re: Hot Standy introduced problem with query cancel behavior

On Thu, 2010-01-07 at 19:23 +0100, Andres Freund wrote:
> On Thursday 07 January 2010 19:12:31 Tom Lane wrote:
> > 
> > As far as I can think at the moment, the best you can do is throw the
> > elog(ERROR), and if control gets out to the error recovery block in
> > PostgresMain, you can force a transaction abort there.  In other words,
> > pretty much the same logic that was there before; the only addition that
> > I think is safe is to allow this to happen while DoingCommandRead, so
> > that you can cancel an idle transaction.
> Stupid question:
> 
> Why dont we add CHECK_FOR_INTERRUPTS (or something similar) to everything 
> calling recv (especially in the EINTR) case? 
> That way we can simply abort in the normal context without the constraint of 
> an interrupt handler because recv() will finish after having serviced a signal 
> handler.
> 
> Sure there will be some parts calling CHECK_FOR_INTERRUPTS not often enough 
> but thats surely not that critical - and after some time using a bit more 
> force is ok I guess.

There's only a need for an immediate death when we were waiting for a
lock. In other cases a deferred death is possible. We could do that in
various places, such as each time we access a new data block.

-- 
 Simon Riggs           www.2ndQuadrant.com