Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 9AB7B9FB801 for ; Fri, 22 Jun 2007 08:41:47 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 13594-10 for ; Fri, 22 Jun 2007 08:41:42 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mail01.enterprisedb.com (mail01.enterprisedb.com [63.246.7.168]) by postgresql.org (Postfix) with ESMTP id 302029FB7D3 for ; Fri, 22 Jun 2007 08:41:42 -0300 (ADT) thread-index: Ace0wlYgVcTEHou/QD+BRscLnUohbw== 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 07:41:55 -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: "Dan Gorman" Cc: "Toru SHIMOGAKI" , "Tom Lane" , In-Reply-To: <31812EEE-22E7-41CD-B70F-CE861681BABC@hi5.com> 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> Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 22 Jun 2007 12:38:09 +0100 Message-ID: <1182512289.9276.220.camel@silverbirch.site> MIME-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2007 11:41:56.0421 (UTC) FILETIME=[5614D750:01C7B4C2] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200706/525 X-Sequence-Number: 25558 On Fri, 2007-06-22 at 04:10 -0700, Dan Gorman wrote: > 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 ... Postgres *is* completely unaware that you intend to take a backup, that is *exactly* why you must tell the server you intend to make a backup, using pg_start_backup() and pg_stop_backup(). That way Postgres will flush its buffers, so that they are present on storage when you make the backup. Is the procedure for Oracle or any other transactional RDBMS any different? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com