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 they are forced to drill down into all of these log destinations.
That's why a subset of us consider any error message based approaches to
GUC guidance a complete waste of time. I won't even address the rest of
your comments; you're focusing on trivia around something that just
fundamentally isn't useful at all.
My challenge to anyone who things error checking has value for this
issue is to demonstrate how that would play out usefully on a mainstream
Postgres system like RHEL/CentOS, Debian, or even Windows Put your
bogus setting in the config file, activate that config file in a
Postgres that looks for the round errors people dislike, and show me how
that mistake is made apparent to the user who made it. I've done
similar exercises myself, and my guess is that if the system is up at
all, those error messages went by completely unnoticed.
--
Greg Smith greg.smith@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/