Re: Hot Standy introduced problem with query cancel behavior

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Hot Standy introduced problem with query cancel behavior
Дата
Msg-id 201001072103.19216.andres@anarazel.de
обсуждение исходный текст
Ответ на Re: Hot Standy introduced problem with query cancel behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Hot Standy introduced problem with query cancel behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thursday 07 January 2010 19:49:59 Tom Lane wrote:
> 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. 
I did not want to suggest using Simons code there. Sorry for the brevity.

The reason I suggested adding CHECK_FOR_INTERRUPTS into the recv code path was 
that it should allow a relatively "natural" handling of canceling "IDLE IN 
TRANSACTION" queries without doing anything in the interrupt handler.

I think it shouldn't be to hard to make that code path safe for 
CHECK_FOR_INTERRUPTS().

I personally don't think its important to be that nice to a non-cooperating 
backend (i.e. one catching our ERRORs) so I dont see any problems in just 
FATAL'ing it after a couple of tries (the code retries already so...).

Andres


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Serializable Isolation without blocking
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: 8.5alpha3 hot standby crash report (DatabasePath related?)