Tom Lane wrote:
>
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > As far as I see, the introduction of the ImmediateInterruptOK
> > flag made HOLD/RESUME_INTERRUPTS scheme pretty meaningless.
>
> Not at all. The point of HOLD_INTERRUPTS is to disable any
> CHECK_FOR_INTERRUPTS call that might be issued by subroutines
> you call. That's very different from ImmediateInterruptOK, which
> can be set true only in *extremely* limited areas wherein we can
> fully understand the behavior of executing the cancel/die request
> in the signal handler.
As you know there weren't so many CHECK_FOR_INTERRUPTS as
we are worried about and we can check ImmediateInterruptOK
if necessary. For example I think RESUME_INTERRUPTS should
have been
#define RESUME_INTERRUPTS() \
do { \
Assert(InterruptHoldoffCount > 0); \
InterruptHoldoffCount--; \
! if (ImmediateInterruptOK && InterruptPending) \
ProcessInterrupts(); \
} while(0)
from the first. In my impression 1 year ago you introduced
2 pretty opposed schemes in a few days.
>
> > Does 'die' interrupts still really need HOLD/RESUME_INTERRUPTS
> > scheme ? If 'die' interrupts are only for normal shutdown,
> > even LockWaitCancel() isn't needed.
>
> It's needed for cancels. Possibly we could skip it during shutdown,
> but trying to do that seems risky and pointless. (If we skip it
> then we are leaving the lock-manager shared memory in a bad state,
> which is exactly what die() should not do.)
What I meant was to not accept 'die' interrupts immdiately
while waiting for a lock. The lock would be released
naturally by other backends.
regards,
Hiroshi Inoue