Re: Incorrectly reporting config errors

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Incorrectly reporting config errors
Дата
Msg-id CA+TgmoZsxmiHEjXw5ZmFQLXS7GMGR2+8rC6gBArpTMXHeH_myQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Incorrectly reporting config errors  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Incorrectly reporting config errors  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Incorrectly reporting config errors  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
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.

Bikeshedding the wording is, of course, another viable option.  For
that matter, ignoring the problem is a pretty viable option, too.  :-)

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: pg_istready and older versions
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: GIN improvements part 1: additional information