Re: proposal: rounding up time value less than its unit.

Поиск
Список
Период
Сортировка
От David Johnston
Тема Re: proposal: rounding up time value less than its unit.
Дата
Msg-id CAKFQuwbPK522AjJR+L+t8SveeJTFB3Xr_CEL7LvENZ8uay5W8A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: rounding up time value less than its unit.  (Gregory Smith <gregsmithpgsql@gmail.com>)
Список pgsql-hackers
On Thursday, September 25, 2014, Gregory Smith <gregsmithpgsql@gmail.com> wrote:
On 9/25/14, 1:41 AM, David Johnston wrote:
If the error message is written correctly most people upon seeing the error will simply fix their configuration and move on - regardless of whether they were proactive in doing so having read the release notes.

The important part to realize here is that most people will never see such an error message.  There is a person/process who breaks the postgresql.conf, a process that asks for a configuration restart/reload (probably via pg_ctl, and then the postmaster program process creating a server log entry that shows the error (maybe in pgstartup.log, maybe in pg_log, maybe in syslog, maybe in the Windows Event Log)

In practice, the top of that food chain never knows what's happening at the bottom unless something goes so seriously wrong the system is down, [...]

And if the GUC setting here is wrong the system will be down, right?  Otherwise the attempt at changing the setting will fail and so even if the message itself is not seen the desired behavior of the system will remain as it was - which is just as valid a decision rounding to zero or 1.

Just like we don't take responsibility for people not reading release notes or checking their configuration if the DBA is not aware of where the GUCs are being set and the logging destinations that not our problem.

David J.

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Spinlocks and compiler/memory barriers
Следующее
От: Andres Freund
Дата:
Сообщение: Inefficient barriers on solaris with sun cc