Skip site navigation (1) Skip section navigation (2)

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

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql/src backend/tcop/postgres.c include/misc ...
Date: 2002-01-08 00:58:24
Message-ID: 3C3A4430.B41CA4C2@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-committers
Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)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

In response to

Responses

pgsql-committers by date

Next:From: Tom LaneDate: 2002-01-08 01:12:00
Subject: Re: pgsql/src backend/tcop/postgres.c include/misc ...
Previous:From: Tom LaneDate: 2002-01-08 00:08:51
Subject: Re: pgsql/src backend/tcop/postgres.c include/misc ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group