Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?

On Tue, Jun 21, 2022 at 05:22:05PM +1200, Thomas Munro wrote:
> Here's one thing I got a bit confused about along the way, but it
> seems the comment was just wrong:
>
> +                       /*
> +                        * If we can abort just the current
> subtransaction then we are OK
> +                        * to throw an ERROR to resolve the conflict.
> Otherwise drop
> +                        * through to the FATAL case.
> ...
> +                       if (!IsSubTransaction())
> ...
> +                               ereport(ERROR,
>
> Surely this was meant to say, "If we're not in a subtransaction then
> ...", right?  Changed.

Indeed, the code does something else than what the comment says, aka
generating an ERROR if the process is not in a subtransaction,
ignoring already aborted transactions (aborted subtrans go to FATAL)
and throwing a FATAL in the other cases.  So your change looks right.

> I thought of a couple more simplifications for the big switch
> statement in ProcessRecoveryConflictInterrupt().  The special case for
> DoingCommandRead can be changed to fall through, instead of needing a
> separate ereport(FATAL).

The extra business with QueryCancelHoldoffCount and DoingCommandRead
is the only addition for the snapshot, lock and tablespace conflict
handling part.  I don't see why a reason why that could be wrong on a
close lookup.  Anyway, why don't you check QueryCancelPending on top
of QueryCancelHoldoffCount?

> Now we're down to just one ereport(FATAL), one ereport(ERROR), and a
> couple of ways to give up without erroring.  I think this makes the
> logic a lot easier to follow?

Agreed that it looks like a gain in clarity.
--
Michael