Re: Replay attack of query cancel - Mailing list pgsql-hackers

From Stephen R. van den Berg
Subject Re: Replay attack of query cancel
Date
Msg-id 20080813134641.GL12628@cuci.nl
Whole thread Raw
In response to Re: Replay attack of query cancel  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Replay attack of query cancel  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Magnus Hagander wrote:
>Gregory Stark wrote:
>> "Magnus Hagander" <magnus@hagander.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!"


pgsql-hackers by date:

Previous
From: Markus Wanner
Date:
Subject: Re: Transaction-controlled robustness for replication
Next
From: Simon Riggs
Date:
Subject: Re: Transaction-controlled robustness for replication