Gregory Stark wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers