From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dan Gorman <dgorman@hi5.com>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Toru SHIMOGAKI <shimogaki.toru@oss.ntt.co.jp>
Cc: pgsql-performance@postgresql.org
Subject: Re: PITR Backups
Date: Fri, 22 Jun 2007 13:12:02 -0400
Message-ID: <23875.1182532322@sss.pgh.pa.us> (raw)
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>
Dan Gorman <dgorman@hi5.com> 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.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, dgorman@hi5.com, simon@2ndquadrant.com, shimogaki.toru@oss.ntt.co.jp
Subject: Re: PITR Backups
In-Reply-To: <23875.1182532322@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox