Shay Rojansky <roji@roji.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