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.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
