On Fri, 2010-01-01 at 15:31 -0500, Kris Jurka wrote: > > On Thu, 31 Dec 2009, Simon Riggs wrote: > > > On Thu, 2009-12-31 at 15:41 +0100, Joachim Wieland wrote: > > > >> I still think that we should have three transaction cancel modes, one > >> to cancel an idle transaction, another one to cancel a running query > >> and a third one that just cancels the transaction regardless of it > >> being idle or not. This last one is what you are implementing now, and > >> it is what HS wants to do. > > > > pg_cancel_backend() is currently conditional on whether a statement is > > active or not, so should really be called pg_cancel_if_active(). What > > people want is an unconditional way to stop a transaction. I don't see > > the need for 3 modes (and that has nothing to do with HS). > > > > The JDBC driver does want "cancel if active" behavior. The JDBC API > specifies Statement.cancel() where Statement is running one particular > backend query. So it really does want to cancel just that one query. > Already this is tough because of the asynchronous nature of the cancel > protocol and the inability to say exactly what should be cancelled.
OK, I think that is conclusive. CancelRequest's behaviour currently equates to SIGINT, so processCancelRequest() can only use SIGINT if SIGINT's behaviour remains same. I would recommend we make SIGINT do cancel-anything, and handle everything else via SIGUSR1, including CancelRequest. I'm not going to do that; I'm going to make HS conflict resolution work, which means putting in enough infrastructure to allow someone else to make SIGINT changes work at a later time, if appropriate. -- 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
