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.
-Kevin