On Wed, Apr 7, 2010 at 10:50 PM, David Rees <dree...@gmail.com> wrote: > On Wed, Apr 7, 2010 at 7:06 PM, Craig James <craig_ja...@emolecules.com> > wrote: >> On 4/7/10 5:47 PM, Robert Haas wrote: >>> On Wed, Apr 7, 2010 at 6:56 PM, David Rees<dree...@gmail.com> wrote: >>>>> synchronous_commit = off >>>> >>>> You are playing with fire here. You should never turn this off unless >>>> you do not care if your data becomes irrecoverably corrupted. >>> >>> That is not correct. Turning off synchronous_commit is sensible if >>> you don't mind losing the last few transactions on a crash. What will >>> corrupt your database is if you turn off fsync. > > Whoops, you're right. > >> A bit off the original topic, but ... >> >> I set it this way because I was advised that with a battery-backed RAID >> controller, this was a safe setting. Is that not the case? > > Robert has it right - with synchronous_commit off, your database will > always be consistent, but you may lose transactions in the event of a > crash. > > Doesn't matter if you have a BBU or not - all the BBU does is give the > controller the ability to acknowledge a write without the data > actually having been written to disk. > > According to the documentation, with synchronous_commit off and a > default wal_writer_delay of 200ms, it's possible to lose up to a > maximum of 600ms of data you thought were written to disk.
So, IOW, if you're running a social networking web site and your database is full of status updates sent by teenagers to other teenagers, you might judge that turning off synchronous_commit is a reasonable thing to do, if you need the performance. If you're running a bank and your database is full of information on wire transfers sent and received, not so much. ...Robert -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
