On Fri, Oct 22, 2010 at 8:37 AM, Greg Smith <greg@2ndquadrant.com> wrote:
> Tom Lane wrote:
>>
>> You've got entirely too simplistic a view of what the "delta" might be,
>> I fear. In particular there are various sorts of changes that involve
>> inserting the data carried in the WAL record and shifting pre-existing
>> data around to make room, or removing an item and moving remaining data
>> around. If you try to replay that type of action against a torn page,
>> you'll get corrupted results.
>>
>
> I wasn't sure exactly how those were encoded, thanks for the clarification.
> Given that, it seems to me there are only two situations where
> full_page_writes is safe to turn off:
>
> 1) The operating system block size is exactly the same database block size,
> and all writes are guaranteed to be atomic to that block size.
> 2) You're using a form of journaled filesystem where data blocks are never
> updated, they're always written elsewhere and the filesystem is redirected
> to that new block once it's on disk.
>
> Looks to me like whether or not there's a non-volatile write cache sitting
> in the middle, like a BBU protected RAID card, doesn't really make any
> difference here then.
>
> I think that most people who have thought they were safe to turn off
> full_page_writes in the past did so because they believed they were in
> category (1) here. I've never advised anyone to do that, because it's so
> difficult to validate the truth of. Just given that, I'd be tempted to join
> in on suggesting this parameter just go away in the name of safety, except
> that I think category (2) here is growing now. ZFS is the most obvious
> example where the atomic write implementation seems to always make disabling
> full_page_writes safe.
>
For the sake of argument, has PG considered using a double write
buffer similar to InnodB?
--
Rob Wultsch
wultsch@gmail.com
