Re: "stuck spinlock"

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "stuck spinlock"
Дата
Msg-id 32556.1386962274@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: "stuck spinlock"  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Logging WAL when updating hintbit
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Extension Templates S03E11