From: | "Stephen R(dot) van den Berg" <srb(at)cuci(dot)nl> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Replay attack of query cancel |
Date: | 2008-08-13 13:46:41 |
Message-ID: | 20080813134641.GL12628@cuci.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander wrote:
>Gregory Stark wrote:
>> "Magnus Hagander" <magnus(at)hagander(dot)net> writes:
>> 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.
Why didn't they follow recommended practice to process any message
anytime? Was/is there a specific reason to avoid that in that driver?
(Just curious).
>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?)
You only need to keep the runtimeparameter for as long as you don't bump
the protocol version.
Then again, runtimeparameters are cheap.
--
Sincerely,
Stephen R. van den Berg.
"And now for something *completely* different!"
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-08-13 13:59:22 | Re: Replay attack of query cancel |
Previous Message | Markus Wanner | 2008-08-13 13:38:32 | Re: Transaction-controlled robustness for replication |