Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> The problem was (third IIRC here :-P) in other clients, such as the JDBC >> driver (I think that one was checked specifically) which currently only >> accept the BackendKeyData message during startup. All drivers not based >> on libpq would have to be checked and potentially updated, but it's >> sitll a lot easier than DHing or so. > > The other problem was getting the new cancel key from the postmaster to > the backend and thence to the client (hopefully in a timely manner), > recognizing that (a) we don't want the postmaster touching shared memory > very much, and certainly not engaging in any locking behavior; (b) > backends feel free to ignore SIGINT when they're not doing anything.
In EXEC_BACKEND, we already store this in shared memory. If we could live with doing that for the non-exec case as well, it'd be a lot easier. And we could then just have the backend update the array when it sends out a "new key" message. > Certainly the prospect of a de facto protocol change is the bigger > problem, but there are nontrivial implementation issues in the server > too. Yeah. > If we were going to make it a de jure protocol change (ie new version > number) instead of just hoping nobody notices the behavioral difference, > I'd be inclined to think about widening the cancel key, too. 32 bits > ain't that much randomness anymore. That, or rely on something that's not just a simple shared secret (something like what Andrew Gierth suggested). And AFAICS, his suggestion allows us to manage without having to update the cancel key in shared memory at all - but it does require a protocol modification. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers