Re: Proposed change to make cancellations safe

On 24 April 2016 at 13:04, Shay Rojansky <roji(at)roji(dot)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