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 flat)
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           www.2ndQuadrant.com


In response to

Responses

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-2014 The PostgreSQL Global Development Group