Re: [HACKERS] Point in Time Recovery

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: markw(at)osdl(dot)org, pgman(at)candle(dot)pha(dot)pa(dot)us, kn(at)mgnet(dot)de, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Point in Time Recovery
Date: 2004-07-19 03:03:01
Message-ID: 8063.1090206181@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers pgsql-patches

Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2004-07-19 03:13:50 Re: [HACKERS] Point in Time Recovery
Previous Message Scott Marlowe 2004-07-18 22:37:06 Re: Help - Error in createdb

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-07-19 03:06:33 CVS compile failure
Previous Message Greg Stark 2004-07-19 02:44:36 Re: Escaping metacharacters

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-07-19 03:13:50 Re: [HACKERS] Point in Time Recovery
Previous Message Andreas Pflug 2004-07-18 22:20:10 Re: logfile subprocess and Fancy File Functions