To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Simon Riggs <simon@2ndquadrant.com>, markw@osdl.org, kn@mgnet.de,
	pgsql-patches@postgresql.org
Subject: Re: [HACKERS] Point in Time Recovery 
In-reply-to: <200407190321.i6J3LVY08349@candle.pha.pa.us> 
References: <200407190321.i6J3LVY08349@candle.pha.pa.us>
Comments: In-reply-to Bruce Momjian <pgman@candle.pha.pa.us>
	message dated "Sun, 18 Jul 2004 23:21:31 -0400"
Date: Sun, 18 Jul 2004 23:49:22 -0400
Message-ID: <8453.1090208962@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.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