On 2015-06-24 17:20:31 -0400, Robert Haas wrote:
> On Wed, Jun 24, 2015 at 3:49 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2015-06-24 15:41:22 -0400, Peter Eisentraut wrote:
> >> On 6/24/15 3:13 PM, Andres Freund wrote:
> >> > Meh. The relevant branches already exist, as you can disable it today.
> >> >
> >> > We could also just change the default in the back branches.
> >>
> >> One more argument for leaving everything alone. If users don't like it,
> >> they can turn it off themselves.
> >
> > Because it's so obvious to get there from "SSL error: unexpected
> > message", "SSL error: bad write retry" or "SSL error: unexpected record"
> > to disabling renegotiation. Right? Search the archives and you'll find
> > plenty of those, mostly in relation to streaming rep. It took -hackers
> > years to figure out what causes those, how are normal users supposed to
> > a) correlate such errors with renegotiation b) evaluate what do about
> > it?
>
> We could document the issues, create release-note entries suggesting a
> configuration change, and/or blog about it.
The situation is this: We have broken code using broken code. I think we
either got to apply, darn nontrivial, fixes from
http://archives.postgresql.org/message-id/54DE6FAF.6050005%40vmware.com
or we got to cripple the options.
It's also not the first breakage, we've applied a lot of bandaids to
this code already. Our way of doing renegotiation also has broken
several SSL client implementations...
Right now if you use streaming rep over ssl, it breaks after a couple
hundred megabytes with obscure errors. The user might or might not
notice that. He might just see errors around syncrep or something. Or
notice that logical decoding never finishes streaming out one huge as
xact, or ...
> I don't accept the argument that there are not ways to tell users
> about things they might want to do.
We probably could do that. But why would we want to? It's just as much
work, and puts the onus on more people?
Greetings,
Andres Freund