From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Remove fsync ON/OFF as a visible option? |
Date: | 2015-03-26 19:59:20 |
Message-ID: | 55146518.30906@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/25/15 8:35 PM, Jeff Janes wrote:
> On Wed, Mar 25, 2015 at 12:45 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com
> <mailto:Jim(dot)Nasby(at)bluetreble(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-03-26 20:14:53 | Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 |
Previous Message | Arthur Silva | 2015-03-26 19:45:17 | Re: pg_rewind in contrib |