[snip]
I'm looking (at Magnus' suggestion) at implementing this.
There appears to be only one significant obstacle; since the query
cancel message is received _after_ forking a new backend, there has to
be some mechanism for recording the new value of N on success. This
is obviously fairly easy in the EXEC_BACKEND case, but it seems quite
intrusive a change to have the non-EXEC_BACKEND case use shared memory
as well.
I can think of a couple of other ways to do it (e.g. some standard
Unix pipe tricks) but I'm not sure of what portability assumptions are
usually made. (I'm assuming that Windows always uses EXEC_BACKEND.)
Ideas?
(To sum up the previous discussion, this is the proposal as I understand
it so far:
1. Servers that support secure cancels will report secure_cancel_key in
the startup GUC settings; the value of this key is just randomness
(presumably in hex for convenience).
2. The server accepts either the old-style or the secure cancel
request from the client, but doesn't allow old-style requests
once a valid secure request has been seen.
3. The client doesn't send secure cancel requests unless
secure_cancel_key was reported. The client may or may not choose
to send secure cancels based on whether SSL is in use; we can
leave this decision up to the client in general, even if we make
libpq use secure cancels only in the SSL case.
The upshot is that replay protection is automatically available if
both the client and server support it, and the client chooses to use it.
The net protocol change is one new GUC and one new message format for
the cancel message.)
--
Andrew.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment