Re: Hot Standy introduced problem with query cancel behavior

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.

Now of course the problem with this approach, if you choose to see it as
a problem, is that somebody could trap the error and try to continue
processing. The only way you can positively guarantee that the backend
will give up whatever locks it's holding is if you elog(FATAL) instead
of trying to do normal error processing. So maybe the right thing is to
forget about CONFLICT_MODE_ERROR altogether. How critical is it that an
HS-requested query cancel be any more likely to do anything than a
regular query cancel is?

regards, tom lane