From: Gregory Stark <stark@enterprisedb.com>
To: "Joshua D. Drake" <jd@commandprompt.com>
Cc: "Toru SHIMOGAKI" <shimogaki.toru@oss.ntt.co.jp>,
	"Steve Atkins" <steve@blighty.com>,
	"PostgreSQL Performance" <pgsql-performance@postgresql.org>
Subject: Re: PITR Backups
In-Reply-To: <467BD479.5090603@commandprompt.com> (Joshua D. Drake's message
	of "Fri, 22 Jun 2007 06:54:01 -0700")
Organization: EnterpriseDB
References: <7E0807EE-B970-4869-A248-B838E42AD9EE@hi5.com>
	<9761.1182472005@sss.pgh.pa.us> <467B3459.9030808@oss.ntt.co.jp>
	<B4AE85C4-8E1C-4EF6-B8A4-7B66C26238EA@blighty.com>
	<467B7A89.3080300@oss.ntt.co.jp> <467BD479.5090603@commandprompt.com>
Date: Fri, 22 Jun 2007 16:31:42 +0100
Message-ID: <87645gngyp.fsf@oxford.xeocode.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


>> So, if any data is written during taking snapshot, we can't assurance data
>> correctness *strictly* .

That sounds nothing like what I've heard called a "snapshot" before. Some
"filesystems" which aren't really filesystems but are also storage layer
drivers like Veritas (and ZFS?) allow you to take a snapshot which they
guarantee is atomic. You can do them while you have concurrent i/o and be sure
to get a single consistent view of the filesystem.

If you're just copying blocks from a device without any atomic snapshot
guarantee then you're going to get garbage. Even in Postgres wasn't writing
anything the OS might still choose to flush blocks during that time, possibly
not even Postgres data blocks but filesystem meta-information blocks.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com