public inbox for [email protected]  

help / color / mirror / Atom feed

From: Joshua D. Drake <[email protected]>
To: Greg Stark <[email protected]>
Cc: Kevin Grittner <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Michael Tharp <[email protected]>
Cc: [email protected]
Cc: Craig Ringer <[email protected]>
Subject: Re: no universally correct setting for fsync
Date: Mon, 10 May 2010 11:42:57 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Mon, 2010-05-10 at 18:46 +0100, Greg Stark wrote:
> On Mon, May 10, 2010 at 4:55 PM, Kevin Grittner
> <[email protected]> wrote:
> > Robert Haas <[email protected]> wrote:
> >
> >> "It might be safe" is a bit of a waffle.  It would be nice if we
> >> could provide some more clear guidance as to whether it is or is
> >> not, or how someone could go about testing their hardware to find
> >> out.
> >
> > I think that the issue is that you could have corruption if some,
> > but not all, disk sectors from a page were written from OS cache to
> > controller cache when a failure occurred.  The window would be small
> > for a RAM-to-RAM write, but it wouldn't be entirely *safe* unless
> > there's some OS/driver environment where you could count on all the
> > sectors making it or none of them making it for every single page.
> > Does such an environment exist?
> 
> The reason for the waffle is that the following sentence describes a
> whole set of environments based the following description:
> 
> > > ? ? ? ?if you have hardware (such as a battery-backed
> > > ? ? ? ?disk controller) or file-system software that reduces the risk
> > > ? ? ? ?of partial page writes to an acceptably low level
> 
> Depending on which set of hardware and how low the risk is it might be safe.
> 
> I think with WAFL or ZFS it's entirely safe. There may be other
> filesystems with similar guarantees. With a BBU the risk might be very
> low -- but it might not, it would be hard to determine without a
> detailed analysis of the entire stack from the buffer cache,
> filesystem, lvm, hardware drivers, BBU design, etc.
> 

The answer to this is:

PostgreSQL.org recommends that this setting be left on at all times.
Turning it off, may lead to data corruption.

Anything else is circumstantial and based on knowledge and facts we
don't have about environmental factors. 

Joshua D. Drake


> -- 
> greg
> 


-- 
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564
Consulting, Training, Support, Custom Development, Engineering

view thread (35+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: no universally correct setting for fsync
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox