Hi all.
Back in 2016 I started a thread about making cancellations safer[1], I'd like to try to pick this up again. Here a summary of the previous conversation:
The main ask here is to allow clients to specify which command to cancel, to avoid various race conditions where the wrong command is accidentally cancelled. The implementation proposal by Tom was for the client and server to simply count messages on each side, and to modify the CancelRequest message for the client to integrate the requested sequence number to be cancelled.
The CancelRequest format change can probably happen in a non-breaking way, e.g. by defining a new cancel request code (the 1234/5678 at the beginning of the message). The client could know that the server is able to accept the new CancelRequest format via a minor protocol bump, or some other means.
There was also discussion of allowing "cancel up to" semantics, where all messages up to the provided sequence number are cancelled. While this could be useful, it's important to allow setting a lower bound as well. A new experimental mode in the Npgsql driver "multiplexes" queries from unrelated threads into the same physical connection, possibly pipelining two unrelated queries go into a single outgoing TCP packet. In this case, the second query producer may issue a cancellation, and unintentionally cancel the first query which is still in progress. So ideally the CancelRequest would contain both a lower and an upper bound (with the lower being optional).
Since cancellation requests may arrive before their target queries do, the backend should be able to track unfulfilled requests and apply them as soon as the target query is received.
Finally, there was also an orthogonal discussion about widening the cancel key (currently 32-bit). However, that seems like it would be a protocol breaking change, so possibly better treated separately.
