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
|
Список | 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 по дате отправления: