Re: BUG #13518: CancelRequest lacks statement identifier

Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> "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.

If I'm correctly visualizing what you've got in mind, it seems like
that would only narrow the race-condition window not close it entirely.
I don't believe there's any guarantee that signals-in-flight are delivered
immediately, so the SIGINT might still arrive at the target process after
it's finished out the transaction that was meant to be canceled.

The bigger picture though is that what you're suggesting would require
that a whole new connection be made in order to issue a Cancel. That's
kind of an expensive solution ... not that what we're doing now is
exactly free, but at least it doesn't fail if you're up against the
MaxBackends limit, for instance.

regards, tom lane