Skip site navigation (1) Skip section navigation (2)

Re: Cancelling idle in transaction state

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Joachim Wieland <joe(at)mcknight(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, James Pye <lists(at)jwp(dot)name>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cancelling idle in transaction state
Date: 2009-12-31 11:10:35
Message-ID: 1262257835.19367.10014.camel@ebony (view raw or whole thread)
Lists: pgsql-hackers
On Thu, 2009-12-24 at 21:38 +0100, Joachim Wieland wrote:
> On Sun, Dec 6, 2009 at 4:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

> I had to write an additional function AbortAnyTransaction() which
> aborts all transactions and subtransactions and leaves the transaction
> in the aborted state, is there an existing function to do this?

My use of AbortOutOfAnyTransaction() was what caused the
problem-I-couldn't-solve. It aborted too far, confusing clients.
Joachim's function does the right thing and leaves the transaction state
correctly, so that clients don't get confused. 

Problem solved, thanks Joachim.

 Simon Riggs 

In response to


pgsql-hackers by date

Next:From: fangfang liuDate: 2009-12-31 11:22:26
Subject: Re: add xml support function
Previous:From: Gurjeet SinghDate: 2009-12-31 10:52:59
Subject: Security vulnerability regarding SET ROLE and REINDEX

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group