Re: Proposed change to make cancellations safe - Mailing list pgsql-hackers

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