Magnus Hagander <[EMAIL PROTECTED]> writes: > 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.
+1 for that one; we have done it already for several send-at-startup parameters that didn't use to be there, eg standard_conforming_strings. I'd go with defining it as the maximum cancel version number supported, eg "cancel_version = 31", with the understanding that if it's not reported then 3.0 should be assumed. So the plan looks like this, I think: * Main FE/BE protocol doesn't change, but there might be an additional value reported in the initial ParameterStatus messages. We believe that this will not break any existing clients. * Server accepts two different styles of cancel messages, identified by different protocol numbers. * Client decides which type to send based on looking for the cancel_version parameter. This seems back-patchable since neither old clients nor old servers are broken: the only consequence of using an old one is your cancels aren't sent securely, which frankly a lot of people aren't going to care about anyway. Note after looking at the postmaster code: the contents of new-style cancel keys ought to be the backend PID in clear, the sequence number in clear, and the hash of backend PID + cancel key + sequence number. If we don't do it that way, the postmaster will need to apply the hash function for *each* backend to see if it matches, which seems like a lot more computation than we want. The postmaster needs to be able to identify which backend is the potential match before executing the hash. The main drawback I can see to keeping this backward-compatible is that keeping the cancel key to 32 bits could still leave us vulnerable to brute force attacks: once you've seen a cancel message, just try all the possible keys till you get a match, and then you can generate a cancel that will work. Can we refine the HMAC idea to defeat that? Otherwise we're assuming that 2^32 HMACs take longer than the useful life of a cancel key, which doesn't seem like a very future-proof assumption. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers