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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
