Message-ID: <4CC1AFB3.3000903@2ndquadrant.com>
Date: Fri, 22 Oct 2010 11:37:23 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	Bruce Momjian <bruce@momjian.us>,
	jd@commandprompt.com, Scott Marlowe <scott.marlowe@gmail.com>,
	Steve Crawford <scrawford@pinpointresearch.com>,
	pgsql-performance@postgresql.org, Ben Chobot <bench@silentmedia.com>
Subject: Re: BBU Cache vs. spindles
References: <4CC04EA50200002500036C5E@gw.wicourts.gov>
	<201010211935.o9LJZTM21744@momjian.us>
	<4CC0513E0200002500036C68@gw.wicourts.gov>
	<4CC1094C.1090306@2ndquadrant.com> <13038.1287720327@sss.pgh.pa.us>
In-Reply-To: <13038.1287720327@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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