Kevin Grittner wrote: > Greg Smith <greg@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
