Re: BUG #13518: CancelRequest lacks statement identifier
От | Kevin Grittner |
---|---|
Тема | Re: BUG #13518: CancelRequest lacks statement identifier |
Дата | |
Msg-id | 773925395.3977925.1438112478191.JavaMail.yahoo@mail.yahoo.com обсуждение исходный текст |
Ответ на | BUG #13518: CancelRequest lacks statement identifier (niallfr@btinternet.com) |
Ответы |
Re: BUG #13518: CancelRequest lacks statement identifier
|
Список | pgsql-bugs |
"niallfr@btinternet.com" <niallfr@btinternet.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
В списке pgsql-bugs по дате отправления: