From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Shay Rojansky <roji(at)roji(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposed change to make cancellations safe |
Date: | 2016-04-24 15:11:45 |
Message-ID: | 7709.1461510705@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2016-04-24 15:31:40 | Re: VS 2015 support in src/tools/msvc |
Previous Message | Shay Rojansky | 2016-04-24 12:04:32 | Proposed change to make cancellations safe |