From: | Kris Jurka <books(at)ejurka(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, 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: | 2010-01-01 20:31:58 |
Message-ID: | alpine.BSO.2.00.1001011527510.1839@leary.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Kris Jurka
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2010-01-01 21:45:43 | Re: Cancelling idle in transaction state |
Previous Message | Kevin Grittner | 2010-01-01 20:12:54 | Re: Serializable Isolation without blocking |