From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Joachim Wieland <joe(at)mcknight(dot)de>, Kris Jurka <books(at)ejurka(dot)com> |
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-29 23:28:07 |
Message-ID: | 1262129287.19367.3407.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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.
Thanks for working on this.
> 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).
(Adding Kris into the discussion here.)
Would this work with JDBC driver and/or general protocol clients?
> 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?
AbortOutOfAnyTransaction()
> We'd probably want to add a timeout for idle transactions also (which
> is a wishlist item since quite some time) and could also offer user
> functions like pg_cancel_idle_transaction(). Along this we might need
> to add internal reasons like we do for SIGUSR1 because we are now
> multiplexing different functionality onto the SIGINT signal. One might
> want to cancel an idle transaction only and not a running query,
> without keeping track of internal reasons one risks to cancel a
> legitimate query if that backend has started to work on a query again.
Next project, not both at once.
--
Simon Riggs www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2009-12-29 23:47:17 | Re: Hot Standy introduced problem with query cancel behavior |
Previous Message | Tom Lane | 2009-12-29 20:32:23 | Re: Stats for inheritance trees |