Re: Cancelling idle in transaction state - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Cancelling idle in transaction state
Date
Msg-id 1262268211.19367.10736.camel@ebony
Whole thread Raw
In response to Re: Cancelling idle in transaction state  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Cancelling idle in transaction state
Re: Cancelling idle in transaction state
List pgsql-hackers
On Thu, 2009-12-31 at 11:10 +0000, Simon Riggs wrote:
> On Thu, 2009-12-24 at 21:38 +0100, Joachim Wieland wrote:
> > On Sun, Dec 6, 2009 at 4:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > > We are using NOTICE, not NOTIFY, assuming that we use anything at all
> > > (which I still regard as unnecessary).  Please stop injecting confusion
> > > into the discussion.
> >
> > Attached is a minimal POC patch that allows to cancel an idle
> > transaction with SIGINT. The HS patch also allows this in its current
> > form but as Simon points out the client gets out of sync with it.
> >
> > The proposal is to send an additional NOTICE to the client and abort
> > all open transactions and subtransactions (this is what I got from the
> > previous discussion).
>
> This all works and I'm looking to post a reviewed patch soon.

Attached is the patch I intend to commit, barring objections.

This patch extends SIGINT to allow cancellation of transactions while
idle in both HS and normal mode. It also changes the standard message
reported on an idle transaction in aborted state to '<IDLE> in
transaction (aborted)', so that once aborted we keep the message even if
the user tries to issue further statements other than ROLLBACK or
COMMIT.

This also solves the bug reported by Kris Jurka.

Joachim, credit will be to you, so please re-check.

(Further changes pending on HS side, so not all issues resolved by this.
I intend to use this mechanism for HS cancellations when
CONFLICT_MODE_ERROR, and another mechanism for CONFLICT_MODE_FATAL.)

--
 Simon Riggs           www.2ndQuadrant.com

Attachment

pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Security vulnerability regarding SET ROLE and REINDEX
Next
From: "Kevin Grittner"
Date:
Subject: Re: A third lock method