From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mark Kirkwood <markir@coretech.co.nz>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: pgsql-admin@postgresql.org
Subject: Re: [HACKERS] Point in Time Recovery
Date: Wed, 21 Jul 2004 22:39:15 -0400
Message-ID: <2110.1090463955@sss.pgh.pa.us> (raw)
In-Reply-To: <40FF1D88.30404@coretech.co.nz>
References: <200407132242.i6DMgg612564@candle.pha.pa.us>
<1089760416.17493.3327.camel@stromboli>
<40F49AE9.2060805@familyhealth.com.au>
<1089789682.17493.3890.camel@stromboli>
<40FF1D88.30404@coretech.co.nz>
Mark Kirkwood <markir@coretech.co.nz> writes:
> Here is one for the 'idiot proof' category:
> 1) initdb and set archive_command
> 2) shutdown
> 3) do a backup
> 4) startup and run some transactions
> 5) shutdown and remove PGDATA
> 6) restore backup
> 7) startup
> Obviously this does not work as the backup is performed with the
> database shutdown.
Huh? It works fine.
The bit you may be missing is that if you blow away $PGDATA including
pg_xlog/, you won't be able to recover past whatever you have in your WAL
archive area. The archive is certainly not going to include the current
partially-filled WAL segment, and it might be missing a few earlier
segments if the archival process isn't speedy. So you need to keep
those recent segments in pg_xlog/ if you want to recover to current time
or near-current time.
I'm becoming more and more convinced that we should bite the bullet and
move pg_xlog/ to someplace that is not under $PGDATA. It would just
make things a whole lot more reliable, both for backup and to deal with
scenarios like yours above. I tried to talk Bruce into this on the
phone the other day, but he wouldn't bite. I still think it's a good
idea though. It would
(1) eliminate the problem that a tar backup of $PGDATA would restore
stale copies of xlog segments, because the tar wouldn't include
pg_xlog in the first place.
(2) eliminate the problem that a naive "rm -rf $PGDATA" would blow away
xlog segments that you still need.
A possible compromise is that we should strongly suggest that pg_xlog
be pushed out to another place and symlinked if you are going to use
WAL archiving. That's already considered good practice for performance
if you have a separate disk spindle to put WAL on. It'll just have
to be good practive for WAL archiving too.
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-admin@postgresql.org
Cc: tgl@sss.pgh.pa.us, markir@coretech.co.nz, simon@2ndquadrant.com
Subject: Re: [HACKERS] Point in Time Recovery
In-Reply-To: <2110.1090463955@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