Re: Re: [RFC] Shouldn't we remove annoying FATAL messages from server log?

Josh Berkus <josh@agliodbs.com> writes:
> On 12/05/2013 10:21 AM, Stephen Frost wrote:
> But ... if we set a firm policy on this, then we could gradually clean
> up the error messages piecemeal over the next couple of major versions.
>  We could also make sure that any new features complied with the
> categorization policy.

> Right now, how to categorize errors is up to each individual patch
> author, which means that things are all over the place, and get worse
> with each new feature added.

I don't think there's that much randomness in is-it-an-ERROR-or-not.
What I believe Stephen is talking about is a classification that
simply doesn't exist today, namely something around how likely is the
message to be of interest to a DBA as opposed to the client application.
We currently compose messages almost entirely with the client in mind,
and that's as it should be.  But we could use some new decoration that's
more DBA-oriented to help decide what goes into the postmaster log.

Before we could get very far we'd need a better understanding than we have
of what cases a DBA might be interested in.  To take the specific example
that started this thread, there wouldn't be a lot of value IMO in a
classification like "connection failure messages".  I think the OP is
probably right that those are often uninteresting --- but as I mentioned,
"too many clients" might become interesting if he's wondering whether he
needs to enlarge max_connections.  Or password failure cases might become
interesting if he starts to suspect breakin attempts.  So I'd want to see
a design that credibly covers those sorts of needs before we put any large
effort into code changes.
        regards, tom lane