Re: "stuck spinlock" - Mailing list pgsql-hackers

From Tom Lane
Subject Re: "stuck spinlock"
Date
Msg-id 32556.1386962274@sss.pgh.pa.us
Whole thread Raw
In response to Re: "stuck spinlock"  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> It seems to me that we should change every place that temporarily
> changes ImmediateInterruptOK to restore the original value instead of
> making assumptions about what it must have been.

No, that's backwards.  The problem isn't that it could be sane to enter,
say, PGSemaphoreLock with ImmediateInterruptOK already true; to get
there, you'd have had to pass through boatloads of code in which it
patently isn't safe for that to be the case.  Rather, the problem is
that once you get there it might *still* be unsafe to throw an error.
HOLD/RESUME_INTERRUPTS are designed to handle exactly that problem.

The only other way we could handle it would be if every path from (say)
HandleNotifyInterrupt down to PGSemaphoreLock passed a bool flag to tell
it "don't turn on ImmediateInterruptOK"; which is pretty unworkable.

> I also really wonder if notify and catchup interrupts ought to be
> taught to respect ImmediateInterruptOK, instead of having their own
> switches for the same thing.

They're not switches for "the same thing" though; the effects are
different, and in fact there are places that do and should flip only some
of these, PGSemaphoreLock being just the most obvious one.  I agree that
it might be possible to simplify things, but it would take more thought
than you seem to have put into it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Logging WAL when updating hintbit
Next
From: Dimitri Fontaine
Date:
Subject: Re: Extension Templates S03E11