On 24 April 2016 at 13:04, Shay Rojansky <roji@roji.org> wrote:
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.
The topic makes sense, an alternate solution may be better.
If things are sequential, both sides can +1 as appropriate. So an extra message isn't required to confirm that. We can resync with optional additional info at various points. Requesting cancellation of a former sequence number can still be blocked.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
