Re: Hot Standy introduced problem with query cancel behavior

On Thursday 07 January 2010 19:12:31 Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > On Thu, 2010-01-07 at 12:14 -0500, Tom Lane wrote:
> >> While we're discussing this: the current coding with
> >> AbortOutOfAnyTransaction within ProcessInterrupts is *utterly* unsafe.
> >> I realize that's just a toy placeholder, but getting rid of it has to be
> >> on the list of stop-ship items. Right at the moment I'd prefer to see
> >> CONFLICT_MODE_ERROR always turned into CONFLICT_MODE_FATAL than to
> >> imagine this is going to work.
> >
> > Hmmm. Can you check my current attempt? This may suffer this problem.
>
> This looks like a mess. You've duplicated a whole lot of code and not
> fixed the fundamental problem.
>
> > If, so can you explain a little more for me? Thanks.
>
> You can not do this from inside an interrupt service routine. Period.
> No amount of deck-chair-rearrangement will fix that.
>
> 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.

Andres