Re: Hot Standy introduced problem with query cancel behavior

On Thu, Jan 7, 2010 at 7:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.

Sorry, but to be clear about this, what do you mean with "allow this
to happen"? You mean that while DoingCommandRead it should be safe to
abort the transaction even from the signal handler or only from the
sigjmp catcher?

> 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?

Simon, couldn't you just translate the conflict modes to the other
cancel modes depending on DoingCommandRead (which is to be determined
from within ProcessInterrupts(), not before).

CONFLICT_MODE_ERROR && !DoingCommandRead => cancel running query
(QueryCancelPending)
CONFLICT_MODE_ERROR && DoingCommandRead => cancel idle transaction
CONFLICT_MODE_FATAL => cancel session (ProcDiePending)

Joachim