On Tue, Oct 1, 2013 at 4:17 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Oct 1, 2013 at 9:16 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> > wrote: >> Since back branches releases are getting closer, I would like to push >> this to all supported branches. To avoid a compatibility nightmare in >> case the new die-on-delayed-renegotiation behavior turns out not to be >> so great, I think it would be OK to set the error level to WARNING in >> all branches but master (and reset the byte count, to avoid filling the >> log). I would also add a CONTEXT line with the current counter value >> and the configured limit, and a HINT to report to pg-hackers. That way >> we will hopefully have more info on problems in the field. >> >> Anybody opposed to this? > > Yes, warning suck. If things just failed, users would fix them, but > instead they fill up their hard disk, and then things fail much later, > usually when they are asleep in bed. > > 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. However, do we think we'll actually *get* any reports in of it if we do that? As in would we trust the input? 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. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
