Re: Remove fsync ON/OFF as a visible option?

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

In response to

Browse pgsql-hackers by date

  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