Re: Proposed change to make cancellations safe

Shay Rojansky <roji@roji.org> writes:
>> We really do need "cancel up to" semantics for reliable behavior.
>> Consider the case where the client has sent the query (or thinks it has)
>> but the server hasn't received it yet.  If the cancel request can arrive
>> at the server before the query fully arrives, and we don't have "cancel
>> all messages up through N" semantics, the cancel will not do what the
>> client expects it to.

> Keep in mind that in the case of a cancellation arriving really too early,
> i.e. before any messages have been received by the server, it will be
> totally ignored since at the time of reception there's nothing for the
> server to cancel yet.

Right, that's how it works today ...

> This may seem a bit exotic, although if you really
> want to provide air-tight cancellation semantics you could have the server
> track unfulfilled cancellation requests. In other words, if the server
> receives "cancel up to X" and is now processing X-5, the cancellation
> request is kept in memory until X has been duly cancelled.

Exactly my point.  If we're trying to make cancel semantics less squishy,
I think we need to do that; errors in this direction are just as bad as
the late-cancel-arrival case.
        regards, tom lane