Re: BUG #13518: CancelRequest lacks statement identifier

From: Kevin Grittner <kgrittn(at)ymail(dot)com>
To: "niallfr(at)btinternet(dot)com" <niallfr(at)btinternet(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #13518: CancelRequest lacks statement identifier
Date: 2015-07-28 19:41:18
Message-ID: 773925395.3977925.1438112478191.JavaMail.yahoo@mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"niallfr(at)btinternet(dot)com" <niallfr(at)btinternet(dot)com> wrote:

> If CancelRequest could include a statement name (or other means
> of identifying a statement) and did nothing if that statement was
> no longer running by the time the server processed it, the
> usability of CancelRequest would be significantly enhanced.

Would it be sufficient for your purposes to cancel a *transaction*
rather than a *statement*? There is already a virtual transaction
ID exposed in pg_locks, and it could probably be added to
pg_stat_activity; we could probably create a
pg_cancel_transaction() function that took a text representation of
that and only canceled the transaction if it was running. There
would need to be locking on a heavily contended lock or two to make
that happen correctly, but presumably this would not ba a
high-volume activity.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Grittner 2015-07-28 19:47:15 Re: BUG #13520: postgres not connecting with opnerp7.0
Previous Message Jack Douglas 2015-07-28 18:09:25 Re: BUG #13523: Unexplained deadlocks (possible race condition)