Re: Hot Standy introduced problem with query cancel behavior

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Hot Standy introduced problem with query cancel behavior
Дата
Msg-id 5521.1262890199@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Hot Standy introduced problem with query cancel behavior  (Andres Freund <andres@anarazel.de>)
Ответы Re: Hot Standy introduced problem with query cancel behavior
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> Stupid question:

> Why dont we add CHECK_FOR_INTERRUPTS (or something similar) to everything 
> calling recv (especially in the EINTR) case? 

We pretty much have CHECK_FOR_INTERRUPTS everywhere that it's safe
already.  The problem here is not a lack of execution of
CHECK_FOR_INTERRUPTS, but what to do inside it.  Although I pointed to
an interrupt service routine as being the worst case, the fact is that
Simon's code will crash the system in a large number of scenarios even
when ProcessInterrupts is called from CHECK_FOR_INTERRUPTS rather than
directly from the signal handler.  You can't just abort transactions and
then return to a nest of functions that think they still have a live
transaction they can resume.  This is why the standard error code path
has the AbortTransaction call out in the sigjmp catcher, not inside
elog() itself.
        regards, tom lane


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

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: true serializability and predicate locking
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Streaming replication and postmaster signaling