Message-ID: <4C3B3FE8.1030409@2ndquadrant.com>
Date: Mon, 12 Jul 2010 12:16:40 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Brad Nicholson <bnichols@ca.afilias.info>
CC: Thomas Kellerer <spam_eater@gmx.net>, pgsql-admin@postgresql.org
Subject: Re: High Availability: Hot Standby vs. Warm Standby
References: <i172f8$kug$1@dough.gmane.org>	 <4C386B33.8090708@2ndquadrant.com>
	<i1eefg$je9$1@dough.gmane.org>
	<1278941155.29426.44.camel@bnicholson-desktop>
In-Reply-To: <1278941155.29426.44.camel@bnicholson-desktop>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Brad Nicholson wrote:
> One further thing to mention - all of these solutions are based on
> making the physical blocks available (actually, I'm not sure about
> Streaming replication in 9.0).

You're right here; the SR feature in 9.0 is essentially near real-time 
partial WAL file shipping, and the WAL contains physical disk block 
change data.  If your master has data blocks corrupted, the next time 
you do a base backup against it that corruption will be mirrored to the 
standby too.  I've mentioned on one of these lists recently that I like 
to schedule a periodic pg_dump even if log shipping is the main backup 
mechanism for a database, just so that corruption in the underlying 
files is caught as early as possible by trying to read every block and 
confirm it has valid data.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us