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
Re: Incorrectly reporting config errors |
Список | 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 по дате отправления: