Re: Hot Standy introduced problem with query cancel behavior
От | Simon Riggs |
---|---|
Тема | Re: Hot Standy introduced problem with query cancel behavior |
Дата | |
Msg-id | 1262890750.19367.87918.camel@ebony обсуждение исходный текст |
Ответ на | Re: Hot Standy introduced problem with query cancel behavior (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Thu, 2010-01-07 at 19:23 +0100, Andres Freund wrote: > On Thursday 07 January 2010 19:12:31 Tom Lane wrote: > > > > As far as I can think at the moment, the best you can do is throw the > > elog(ERROR), and if control gets out to the error recovery block in > > PostgresMain, you can force a transaction abort there. In other words, > > pretty much the same logic that was there before; the only addition that > > I think is safe is to allow this to happen while DoingCommandRead, so > > that you can cancel an idle transaction. > Stupid question: > > Why dont we add CHECK_FOR_INTERRUPTS (or something similar) to everything > calling recv (especially in the EINTR) case? > That way we can simply abort in the normal context without the constraint of > an interrupt handler because recv() will finish after having serviced a signal > handler. > > Sure there will be some parts calling CHECK_FOR_INTERRUPTS not often enough > but thats surely not that critical - and after some time using a bit more > force is ok I guess. There's only a need for an immediate death when we were waiting for a lock. In other cases a deferred death is possible. We could do that in various places, such as each time we access a new data block. -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: