Re: SSL renegotiation

On Tue, Oct 1, 2013 at 10:19 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> If we can't feel comfortable with an ERROR, let's not do it at all.
>
> In principle, I agree.
>
> However, if we want to do this as a temporary measure to judge impact,
> we could do WARNING now and flip it to ERROR in the next minor
> release.

I can't imagine that whacking the behavior around multiple times is
going to please very many people. And, from a practical standpoint,
the time between minor releases is typically on the order of ~3
months. That's not very long. The situations in which trouble occurs
are likely to obscure, and a lot of users don't apply every minor
release, or don't apply them in a timely fashion. So I can't see that
this strategy would increase our confidence very much anyway. In
other words...

> However, do we think we'll actually *get* any reports in of it if we
> do that? As in would we trust the input?

...no.

> If we do, the it might be
> worth doing that. If we don't believe we'll get any input from the
> WARNINGs anyway, we might as well flip it to an ERROR. But if we do
> flip it to an ERROR, we should have a way to disable that error if, as
> Alvaro puts it, we end up breaking too many things.

A way of disabling the error seems like an awfully good idea. Since I
know my audience, I won't suggest the obvious method of accomplishing
that goal, but I think we all know what it is.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company