"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?). 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! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers