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
