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

From: David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Gregory Smith <gregsmithpgsql(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: rounding up time value less than its unit.
Date: 2014-09-25 13:32:17
Message-ID: CAKFQuwbPK522AjJR+L+t8SveeJTFB3Xr_CEL7LvENZ8uay5W8A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, September 25, 2014, Gregory Smith <gregsmithpgsql(at)gmail(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-09-25 13:34:59 Inefficient barriers on solaris with sun cc
Previous Message Robert Haas 2014-09-25 13:25:16 Re: Spinlocks and compiler/memory barriers