On 3/25/15 8:35 PM, Jeff Janes wrote:
On Wed, Mar 25, 2015 at 12:45 PM, Jim Nasby <jim.na...@bluetreble.com <mailto:jim.na...@bluetreble.com>> wrote: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! :) But one of these things is not like the other. Any supported (i.e. non fatal erroring) setting of wal_sync_method *should* always be safe (although may be inefficient) if the underlying kernel, RAID controller, hard drives, and fs fulfill their pledges. It is hard to document every known liar in this regard. About the best you can do, short of pull-the-plug test on a massive scale, is to run pg_fsync_test and assuming that any result inconsistent with the RPM of the spinning rust is obviously unsafe. Unfortunately that doesn't rule out the possibility that something is both unsafe and gratuitously slow.
I agree, but the reason I include this setting as dangerous is you really don't know what you're getting into once you move past fsync unless you actually study it and/or do testing. To me, that makes that setting dangerous.
-- 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
