On Thursday 07 January 2010 21:47:47 Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > The reason I suggested adding CHECK_FOR_INTERRUPTS into the recv code
> > path was that it should allow a relatively "natural" handling of
> > canceling "IDLE IN TRANSACTION" queries without doing anything in the
> > interrupt handler.
> >
> > I think it shouldn't be to hard to make that code path safe for
> > CHECK_FOR_INTERRUPTS().
>
> Idle in transaction isn't the problem (except for what it does to the
> FE/BE protocol state). The problem is what happens inside a non-idle
> transaction.
>
> Since apparently I'm still not being clear enough about this, let me
> spell it out:
> 5. According to both Simon's committed patch and his recent variant,
> ProcessInterrupts executes AbortOutOfAnyTransaction and then throws
> elog(ERROR).
> Andres Freund <andres@anarazel.de> writes:
> > I did not want to suggest using Simons code there. Sorry for the brevity.
should have read as "revert to old code and add two step killing (thats likely
around 10 lines or so)".
"two step killing" meaning that we signal ERROR for a few times and if nothing
happens that we like, we signal FATAL.
As the code already loops around signaling anyway that should be easy to
implement.
I have no doubt about you being right that its not practical (even more so at
this point in the release cycle) to make that AbortOutOfAnyTransaction call.
Andres
PS: Thats procarray.c: ResolveRecoveryConflictWithVirtualXIDs