"Magnus Hagander" <magnus@hagander.net> writes:
> Yeah, that's the point that will require a protocol bump, I think. Since
> there is no response to the cancel packet, we can't even do things like
> sending in a magic key and look at the response (which would be a rather
> ugly hack, but doable if we had a success/fail response to the cancel
> packet).
From the server point of view we could accept either kind of cancel message
for the first cancel message and set a variable saying which to expect from
there forward. If the first cancel message is an old-style message then we
always expect old-style messages. If it's a new-style message then we require
new-style messages and keep track of the counter to require a monotically
increasing counter.
From the client point-of-view we have no way to know if the server is going to
accept new-style cancel messages though. We could try sending the new-style
message and see if we get an error (do we get an error if you send an invalid
cancel message?).
We could have the server indicate it's the new protocol by sending the initial
cancel key twice. If the client sees more than one cancel key it automatically
switches to new-style cancel messages.
Or we could just bump the protocol version.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!