On 3/20/15 6:09 PM, Robert Haas wrote:
> On Fri, Mar 20, 2015 at 3:26 PM, Joshua D. Drake <jd@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