To: Simon Riggs <simon@2ndquadrant.com>
Cc: markw@osdl.org, pgman@candle.pha.pa.us, kn@mgnet.de,
	pgsql-patches@postgresql.org
Subject: Re: [HACKERS] Point in Time Recovery 
In-reply-to: <1089845797.17493.4987.camel@stromboli> 
References: <200407141555.i6EFtnk22984@mail.osdl.org>
	<1089833620.17493.4624.camel@stromboli>
	<1089845797.17493.4987.camel@stromboli>
Comments: In-reply-to Simon Riggs <simon@2ndquadrant.com>
	message dated "Wed, 14 Jul 2004 23:56:39 +0100"
Date: Sun, 18 Jul 2004 23:03:01 -0400
Message-ID: <8063.1090206181@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Simon Riggs <simon@2ndquadrant.com> writes:
> Latest version, pitr_v5_2.patch...

Reviewed and committed with some adjustments.

I see the following significant loose ends:

* 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.)

* As Bruce has pointed out already, the process of making a backup
needs some improvements for more safety: the starting and ending WAL
offsets have got to be recorded somehow.

* As I have pointed out already, we need to invent "timelines" to
allow incompatible WAL segments to exist side-by-side.  I will volunteer
to look into this.

* I think creating a .ready file during XLogFileOpen is completely bogus,
for reasons mentioned in committed comments (look for XXX).  Possibly
this can go away with timelines.

* I am wondering if it wouldn't be a good idea to remove the local copy
of any segment we successfully obtain from archive.  The existing
comments note that we might get a wrong or corrupted file from archive,
but aren't we in at least as much risk of using an obsolete segment
restored from backup if we leave the local segment in place?  (The
archive recovery run itself will know not to do this, but if we crash
shortly thereafter, the ensuing recovery run would NOT know not to
trust such files.)

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.  Can we redesign either the
backup process or the disk layout so that that will not happen?  Then
we could stop worrying about stale local pg_xlog files.

			regards, tom lane