Re: no universally correct setting for fsync - Mailing list pgsql-hackers

From Greg Stark
Subject Re: no universally correct setting for fsync
Date
Msg-id u2n407d949e1005101046weac382a6g99a5c932d4c5b736@mail.gmail.com
Whole thread Raw
In response to Re: no universally correct setting for fsync  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: no universally correct setting for fsync
Re: no universally correct setting for fsync
List pgsql-hackers
On Mon, May 10, 2010 at 4:55 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Robert Haas <robertmhaas@gmail.com> 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.

--
greg


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: max_standby_delay considered harmful
Next
From: Tom Lane
Date:
Subject: Re: [BUGS] "SET search_path" clause ignored during function creation