From: | David Rees <drees76(at)gmail(dot)com> |
---|---|
To: | Craig James <craig_james(at)emolecules(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Occasional giant spikes in CPU load |
Date: | 2010-04-08 02:50:35 |
Message-ID: | y2l72dbd3151004071950kfe09a98fqf0c9a136375260e2@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Apr 7, 2010 at 7:06 PM, Craig James <craig_james(at)emolecules(dot)com> wrote:
> On 4/7/10 5:47 PM, Robert Haas wrote:
>> On Wed, Apr 7, 2010 at 6:56 PM, David Rees<drees76(at)gmail(dot)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.
-Dave
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-04-08 03:07:18 | Re: Occasional giant spikes in CPU load |
Previous Message | Craig James | 2010-04-08 02:06:15 | Re: Occasional giant spikes in CPU load |