On Wed, 2009-12-30 at 12:05 +0100, Joachim Wieland wrote: > On Tue, Dec 29, 2009 at 4:22 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > This seems like a fairly bad idea. One of the intended use-cases is to > > be able to manually "kill -INT" a misbehaving backend. Assuming that > > there will be valid info about the signal in shared memory will break > > that. > > I never intended to change the current behavior. > > Actually I wanted to even enhance it by allowing to also cancel an idle > transaction via SIGINT. We are free to define what should happen if there is > no > internal reason available because the signal has been sent manually. > > We can also use SIGUSR1 of course but then you cannot cancel an idle > transaction just from the commandline. Not sure if this is necessary > though but I would have liked it in the past already (I once used a version of > slony that left transactions idle from time to time...)
Andres mentioned this in relation to Startup process sending signals to backends. Startup needs to in-some cases issue a FATAL error also, which is a separate issue from the discusion around SIGINT. I will rework the FATAL case and continue to support you in finding a solution to the cancel-while-idle case. -- 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
