Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 4B6EC9FC5D4 for ; Fri, 22 Jun 2007 14:49:37 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 85564-01-8 for ; Fri, 22 Jun 2007 14:49:28 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail01.enterprisedb.com (mail01.enterprisedb.com [63.246.7.168]) by postgresql.org (Postfix) with ESMTP id D98579FC5C9 for ; Fri, 22 Jun 2007 14:49:29 -0300 (ADT) thread-index: Ace09beUt5MaB7n0QuqrwJcaQK6j3A== Received: from [192.168.0.4] ([85.211.241.229]) by mail01.enterprisedb.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jun 2007 13:49:43 -0400 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073 Subject: Re: PITR Backups From: "Simon Riggs" To: "Tom Lane" Cc: "Dan Gorman" , "Toru SHIMOGAKI" , In-Reply-To: <23875.1182532322@sss.pgh.pa.us> References: <7E0807EE-B970-4869-A248-B838E42AD9EE@hi5.com> <9761.1182472005@sss.pgh.pa.us> <467B3459.9030808@oss.ntt.co.jp> <1182509748.9276.178.camel@silverbirch.site> <31812EEE-22E7-41CD-B70F-CE861681BABC@hi5.com> <23875.1182532322@sss.pgh.pa.us> Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 22 Jun 2007 18:45:57 +0100 Message-ID: <1182534358.9276.326.camel@silverbirch.site> MIME-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2007 17:49:43.0734 (UTC) FILETIME=[B7399560:01C7B4F5] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200706/544 X-Sequence-Number: 25577 On Fri, 2007-06-22 at 13:12 -0400, Tom Lane wrote: > Dan Gorman writes: > > This snapshot is done at the LUN (filer) level, postgres is un-aware > > we're creating a backup, so I'm not sure how pg_start_backup() plays > > into this ... > > That method works too, as long as you snapshot both the data files and > WAL files --- when you start PG from the backup, it will think it > crashed and recover by replaying WAL. So, assuming that the snapshot > technology really works, it should be exactly as reliable as crash > recovery is. > If you saw a problem I'd be inclined to question whether > there is some upstream component (OS or disk controller) that's > reordering writes. Given thats exactly what they do, constantly, I don't think its safe to say that it works since we cannot verify whether that has happened or not. At the very least, you should issue a CHECKPOINT prior to taking the snapshot, to ensure that the write barriers have gone through. But that being said, I'm not quite sure why following the Continuous Archiving procedures is a problem, since they don't add any significant overhead, over and above the checkpoint command. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com