Gregory Stark wrote:
> "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?).
No, that is the point I made above - we don't respond to the cancel
message *at all*.
> 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.
That will still break things like JDBC I think - they only expect one
cancel message, and then move on to expect other things.
> Or we could just bump the protocol version.
Yeah, but that would kill backwards compatibility in that the new libpq
could no longer talk to old servers.
What would work is using a parameter field, per Stephen's suggestion
elsewhere in the thread. Older libpq versions should just ignore the
parameter if they don't know what it is. Question is, is that too ugly a
workaround, since we'll need to keep it around forever? (We have special
handling of a few other parameters already, so maybe not?)
//Magnus
