Shay Rojansky <r...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers