Re: no universally correct setting for fsync

On Mon, 2010-05-10 at 18:46 +0100, Greg Stark wrote:
> On Mon, May 10, 2010 at 4:55 PM, Kevin Grittner
>  wrote:
> > Robert Haas  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