A while ago I discussed some reliability issues when using cancellations (
Since we were discussing some protocol wire changes recently I'd like to
propose one to help with that.

The issue I'd like to tackle is the fact that it's not possible to make
sure a cancellation request affects a specific query. Since cancellations
are totally asynchronous and occur on another socket, they affect whatever
query is currently being processed. This makes it possible to inadvertently
kill a later query, because by the time the cancellation request is
delivered and "applied" an the intended query already completed and a later
one gets killed.

A simple fix for this would be to have a sequence number returned in the
BindComplete message. When submitting a cancellation request, the frontend
would have the option (but not the obligation) to pass such as sequence
number to the backend. When cancelling, the backend would make sure the
sequence number corresponds to the currently running query.

The only drawback seems to be the increased payload of the BindComplete
message (4 bytes, or possibly less if we're really worried about it).

If this makes sense, I'll add it to the TODO wiki.


Reply via email to