On 24 April 2016 at 13:04, Shay Rojansky <r...@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/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
