Kevin Grittner wrote:
> Greg Smith <greg@2ndquadrant.com> wrote:
>
> > I think Kevin's point here may be that if your fsync isn't
> > reliable, you're always in trouble. But if your fsync is good,
> > even torn pages should be repairable by the deltas written to the
> > WAL
>
> I was actually just arguing that a BBU doesn't eliminate a risk
> here; if there is a risk with production-quality disk drives, there
> is a risk with a controller with a BBU cache. The BBU cache just
> tends to reduce the window of time in which corruption can occur. I
> wasn't too sure of *why* there was a risk, but Tom's post cleared
> that up.
>
> I wonder why we need to expose this GUC at all -- perhaps it should
> be off when fsync is off and on otherwise? Leaving it on without
> fsync is just harming performance for not much benefit, and turning
> it off with fsync seems to be saying that you are willing to
> tolerate a known risk of database corruption, just not quite so much
> as you have without fsync. In reality it seems most likely to be a
> mistake, either way.
According to our docs, and my submitted patch, if you are using ZFS then
you can turn off full-page writes, so full-page writes are still useful.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +