On 3/21/15 12:25 PM, Jeff Janes wrote:
On Sat, Mar 21, 2015 at 8:54 AM, Tom Lane <t...@sss.pgh.pa.us <mailto:t...@sss.pgh.pa.us>> wrote:Stephen Frost <sfr...@snowman.net <mailto:sfr...@snowman.net>> writes: > At the moment, one could look at our default postgresql.conf and the > "turns forced synchronization on or off" and think it's something akin > or somehow related to synchronous_commit (which is completely different, > but the options are right next to each other..). > How about a big warning around fsync and make it more indepenent from > the options around it? Yeah, the main SGML docs are reasonably clear about the risks of fsync, but postgresql.conf doesn't give you any hint that it's dangerous. Now I'm not entirely sure that people who frob postgresql.conf without having read the docs can be saved from themselves, but we could do something like this: # - Settings - #wal_level = minimal # minimal, archive, hot_standby, or logical # (change requires restart) #fsync = on # turns forced synchronization on or off + # (fsync=off is dangerous, read the + # (manual before using it) #synchronous_commit = on # synchronization level; # off, local, remote_write, or on #wal_sync_method = fsync # the default is the first option # supported by the operating system: Also, I think the short description "turns forced synchronization on or off" could stand improvement; it really conveys zero information. Maybe something like "force data to disk when committing"? I agree the current description is lacking, but that proposed wording would be a better description of synchronous_commit. It is checkpointing and flush-WAL-before-data where fsync=off does its damage. "Force data to disk when needed for integrity"? Or just don't describe what it is at all, and refer to the documentation only.
I see 3 settings that allow people to accidentally shoot themselves in the foot; fsync, wal_sync_method and full_page_writes.
How about just grouping those 3 together with a bulk disclaimer along the lines of "The following 3 settings are dangerous. Use at your own risk, and read the docs first."? That would also allow us to just remove the comments about what the settings do; if you don't already know you certainly shouldn't be touching them! :)
-- 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
