Re: HandleParallelMessages contains CHECK_FOR_INTERRUPTS?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: HandleParallelMessages contains CHECK_FOR_INTERRUPTS?
Дата
Msg-id 14869.1470083848@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: HandleParallelMessages contains CHECK_FOR_INTERRUPTS?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: HandleParallelMessages contains CHECK_FOR_INTERRUPTS?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> $SUBJECT seems like a pretty bad idea, because it implies a recursive
>> entry to ProcessInterrupts and thence to HandleParallelMessages itself.
>> By what reasoning is that call necessary where it's placed?

> I notice you just removed the CHECK_FOR_INTERRUPTS in
> HandleParallelMessages().  Did you notice that HandleParallelMessages
> calls shm_mq_receive(), which calls shm_mq_receive_bytes(), which
> contains a CHECK_FOR_INTERRUPTS() call?

I figured there were probably other cases of recursion; it's unlikely
we could prevent them altogether.  But a check in a function that's
called *only* from ProcessInterrupts seems pretty dubious.

I wonder whether we should make use of HOLD_INTERRUPTS/RESUME_INTERRUPTS
to avoid the recursion scenario here.  It's not really clear to me whether
this stack of function would behave sanely if it's invoked recursively
when the outer level is partway through reading a message.  At the very
least, it seems like there might be a risk for out-of-order message
processing (inner recursion reads and processes next message while outer
level has read but not yet processed previous message).
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: New version numbering practices
Следующее
От: Robert Haas
Дата:
Сообщение: Re: PostmasterContext survives into parallel workers!?