Re: Proposed change to make cancellations safe

I definitely agree that simply tracking message sequence numbers on both
sides is better. It's also a powerful feature to be able to cancel all
messages "up to N" - I'm thinking of a scenario where, for example, many
simple queries are sent and the whole process needs to be cancelled.

Yes, this has been happening to some Npgsql users, it's not very frequent
but it does happen from time to time. I also bumped into this in some
automated testing scenarios. It's not the highest-value feature, but it is
an improvement to have if you plan on working on a new protocol version.

Let me know if you'd like me to update the TODO.

On Sun, Apr 24, 2016 at 6:11 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Shay Rojansky <roji(at)roji(dot)org> writes:
> > 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.
>
> Right ...
>
> > A simple fix for this would be to have a sequence number returned in the
> > BindComplete message.
>
> First, that doesn't fix anything for simple query protocol, which doesn't
> use such a message.
>
> Second, making sure that the BindComplete gets delivered soon enough to be
> useful would require issuing a Sync between Bind and Execute. At the
> least that doubles the number of network packets for small query results
> (so I dispute your assumption that the added network load would be
> negligible). But a bigger issue is that it would have subtle effects
> on error handling. An application could not blindly fire out
> Parse/Bind/Sync/Execute/Sync as one packet; it would have to wait for
> the Bind result to come back before it could know if it's safe to send
> Execute, unlike the case where it sends Parse/Bind/Execute/Sync. (The
> server's skip-to-Sync-after-error rule is critical here.) So actually,
> making use of this feature would double the number of network round trips,
> as well as requiring carefully thought-through changes to application
> error handling.
>
> Third, if a query is not cancellable till Execute, that prevents
> cancellation of scenarios where the parser or planner takes a long time
> for some reason. Long planner runtimes are certainly not uncommon.
>
>
> So this is worth thinking about, but that doesn't sound like much of
> a solution to me.
>
> I wonder though why we need the server to tell the client a sequence
> number at all. Surely both sides of the connection could easily count
> the number of messages the client has transmitted. We could simply extend
> the cancel packet to include a sequence number field, with the semantics
> "this should only take effect if you're still working on message N".
> Or I guess maybe it should read "working on message N or before", so
> that in a case like Parse/Bind/Execute/Sync you would mention the number
> of the Execute message and still get cancellation if the query was hung
> up in Parse.
>
> Have you seen this to be a problem in practice, or is it just
> theoretical? I do not recall many, if any, field complaints
> about the issue.
>
> regards, tom lane
>