Re: pgsql/src backend/tcop/postgres.c include/misc ...

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