Hi. A while ago I discussed some reliability issues when using cancellations ( http://www.postgresql.org/message-id/CADT4RqAk0E10=9ba8v+uu0dq9tr+pn8x+ptqbxfc1fbivh3...@mail.gmail.com). 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. Shay