Re: Proposed change to make cancellations safe

>
> I definitely agree that simply tracking message sequence numbers on both
>> sides is better. It's also a powerful feature to be able to cancel all
>> messages "up to N" - I'm thinking of a scenario where, for example, many
>> simple queries are sent and the whole process needs to be cancelled.
>>
>
> For security, I think any non-matching cancellation would be ignored so
> that only someone with proper context could issue the cancel.
>

Isn't security taken care of by the secret key?

> Issuing bulk cancellations sounds like a bad plan.
>

I'm not sure why, but at the very least it's a useful thing to have when
batching several statements together and then wanting to cancel them all.

> Yes, this has been happening to some Npgsql users, it's not very frequent
>> but it does happen from time to time. I also bumped into this in some
>> automated testing scenarios. It's not the highest-value feature, but it is
>> an improvement to have if you plan on working on a new protocol version.
>>
>> Let me know if you'd like me to update the TODO.
>>
>
> If you've got an itch, expecting someone else to scratch it is less likely
> to succeed.
>

Sure. I'd consider sending in a patch, but as this is a protocol-changing
feature it seems like working on this before the team "officially" starts
working on a new protocol might be a waste of time. Once there's critical
mass for a new protocol and agreement that PostgreSQL is going for it I'd
be happy to work on it.

BTW it seems it's no longer possible for anyone to add things to the TODO
(no editor privileges).