Re: Cancelling idle in transaction state

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

In response to

Responses

Browse pgsql-hackers by date

  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