Re: Incorrectly reporting config errors

On 2014-01-21 16:13:11 -0500, Robert Haas wrote:
> On Tue, Jan 21, 2014 at 3:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> >> I kind of agree with Thom.  I understand why it's doing what it's
> >> doing, but it still seems sort of lame.
> >
> > Well, the point of the message is to report that we failed to apply
> > all the settings requested by the file.  If you prefer some wording
> > squishier than "error", we could bikeshed the message phrasing.
> > But I don't think we should suppress the message entirely; nor does
> > it seem worthwhile to try to track whether all the failures were of
> > precisely this type.
> 
> Well, to me the whole thing smacks of:
> 
> LOG: there is a problem
> LOG: please be aware that we logged a message about a problem
> 
> The only real argument for the message:
> 
> LOG: configuration file "/home/thom/Development/data/postgresql.conf"
> contains errors; unaffected changes were applied
> 
> ...is that somebody might think that the presence of a single error
> caused all the changes to be ignored.  And there's a good reason they
> might think that: we used to do it that way.  But on the flip side, if
> we emitted a LOG or WARNING message every time the user did something
> that works in a way incompatible with previous releases, we'd go
> insane.  So I think the argument for just dumping that message
> altogether is actually pretty good.

I don't find that argument all that convincing. The expectation that a
config file isn't applied if it contains errors is a generally
reasonable one, not just because we used to do it that way. I also don't
see the disadvantage of the current behavour of reporting that we didn't
apply the change. Additionally it makes it easier to look for such
errors, by having a relatively easy to remember message to search for in
the log.

What I think is that we're reporting such problems way too often. The
usual cause I know of is something like:
shared_buffers = 4GB
...
shared_buffers = 6GB

When reloading the config we'll report an error in the line setting it
to 4GB because shared_buffers is PGC_POSTMASTER leading to a spurious
"contains errors" message. Rather annoying.

Now, I am sure somebody will argue along the lines of "well, don't do
that then", but I don't see much merit in that argument. A rather common
and sensible configuration is to have a common configuration file used
across servers, which then is overwritten by a per-server or per-cluster
config file containing values specific to a server/cluster.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services