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
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) |