From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: markw@osdl.org
Cc: kn@mgnet.de
Cc: pgsql-patches@postgresql.org
Subject: Re: [HACKERS] Point in Time Recovery
Date: Sun, 18 Jul 2004 23:49:22 -0400
Message-ID: <8453.1090208962@sss.pgh.pa.us> (raw)
In-Reply-To: <200407190321.i6J3LVY08349@candle.pha.pa.us>
References: <200407190321.i6J3LVY08349@candle.pha.pa.us>
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> * Documentation is, um, lacking. (One point in particular is that I
>> inserted the recovery.conf.sample file into CVS, but did not fill in
>> the patch's lack of attempt to install it anywhere.)
> I figure it should go in share like the other sample files, and tell
> people to copy it to /data and modify it for recovery.
It should certainly go to /share as a .sample file. I was thinking that
initdb should perhaps copy it into $PGDATA (still as .sample, not as
.conf!) so it'd be right there when you need it.
>> Perhaps the last point is really a backup-process issue. AFAICS there
>> is no good reason for a backup tarfile to include $PGDATA/pg_xlog at
>> all, and some good reasons for it not to.
> Seems we should just clear out the /pg_xlog directory before we start
> recovery.
No, that's a horrid idea, because it loses the ability to combine
archival xlog files with recent files in /pg_xlog that are not yet
archived. We need to distinguish old files that were accidentally
captured by backup from very-recent files. I think the cleanest way to
do that is for backup not to capture them in the first place.
> We are going to rename recovery.conf to recovery.in-progress
> or something to prevent us from clearing out the directory after a
> crash, right?
I had second thoughts about that and didn't do it in the committed
patch, though it's certainly still open for debate.
> (I see you rename recovery.conf to recovery.done. Is
> that wise?
Yes. Once you've done with a PITR recovery you definitely do *not* want
a subsequent crash recovery to think it should obey your recovery_target
limit. But if you fail before you've finished the recovery run it
should theoretically be okay to retry, so I didn't add code to rename to
"recovery.inprogress". We can certainly add it later if we decide it's
a good idea.
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, pgman@candle.pha.pa.us, simon@2ndquadrant.com, markw@osdl.org, kn@mgnet.de, pgsql-patches@postgresql.org
Subject: Re: [HACKERS] Point in Time Recovery
In-Reply-To: <8453.1090208962@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