On 3/20/15 6:09 PM, Robert Haas wrote:
On Fri, Mar 20, 2015 at 3:26 PM, Joshua D. Drake <j...@commandprompt.com> wrote:
Fair enough. I am not going to name names but over the years (and just
today) I ran into another user that corrupted their database by turning off
fsync.
My experience is different than yours: I haven't found this to be a
particularly common mistake. I think I've had more people screw
themselves by setting autovacuum_naptime=something_excessively_large
or enable_seqscan=off.
FWIW, I suspect a lot of that is due to CMD and EDB targeting different
markets.
I'm very skeptical that removing stuff from postgresql.conf is going
to help anything. If you go through your postgresql.conf and change
settings at random, bad things will happen. But anyone who is doing
that has a problem we can't fix.
I don't think people are making random changes; they're misunderstanding
what the setting actually does. For dangerous settings (fsync,
wal_sync_method and full_page_writes come to mind), a big WARNING in
postgresql.conf would go a long way towards improving that.
I do agree that simply removing the option isn't a great solution.
Thus far, the rule for postgresql.conf has been that pretty much
everything goes in there, and that's a defensible position. Other
reasonable options would be to ship the file with a small handful of
settings in it and leave everything else, or to ship it completely
empty of comments with only those settings that initdb sets and
nothing else. I'd be OK a coherent policy change in this area, but
just removing one or two setting seems like it will be confusing
rather than helpful.
I agree with not being ad-hoc (and I think a documented postgresql.conf
is much better than the other options).
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
