I wrote:
> No, the problem is merely to get LockWaitCancel to return "true" so that
> StatementCancelHandler will go ahead with the immediate interrupt. No
> new cleanup is needed other than resetting the new flag.
Actually there's a better way to do it: we can remove a little bit of
complexity instead of adding more. The basic problem is that
StatementCancelHandler wants to tell the difference between waiting for
client input (which there is no use for it to interrupt) and other
states in which ImmediateInterruptOK is set. ProcWaitForSignal() is
falling on the wrong side of the classification --- and I argue that any
other newly added interruptable wait would too. We should reverse the
sense of the test so that it's "not in client input" instead of "in lock
wait". At the time that code was written, there wasn't any conveniently
cheap way to check for client input state, so we kluged up
LockWaitCancel to detect the other case. But now that we have the
DoingCommandRead flag, it's easy to check that. This lets us remove
LockWaitCancel's return value (which was always a bit untidy, since all
but one of its callers ignored the result), ending up with exactly
parallel code in die() and StatementCancelHandler(). Seems cleaner than
before.
regards, tom lane