From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, markw(at)osdl(dot)org, kn(at)mgnet(dot)de, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Point in Time Recovery |
Date: | 2004-07-19 03:21:31 |
Message-ID: | 200407190321.i6J3LVY08349@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers pgsql-patches |
Tom Lane wrote:
> 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.)
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.
> * 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.
Yep, we need those files in the archive location and the /data directory
tarball.
> * 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.
Great.
> * 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.
Seems we should just clear out the /pg_xlog directory before we start
recovery. 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 see you rename recovery.conf to recovery.done. Is
that wise? I thought we would disable recovery after a crash, or does
it just keep going? If so, nice.)
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-07-19 03:49:22 | Re: [HACKERS] Point in Time Recovery |
Previous Message | Bruce Momjian | 2004-07-19 03:14:10 | Re: [HACKERS] Point in Time Recovery |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-07-19 03:31:46 | Re: Why we really need timelines *now* in PITR |
Previous Message | Bruce Momjian | 2004-07-19 03:14:10 | Re: [HACKERS] Point in Time Recovery |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-07-19 03:49:22 | Re: [HACKERS] Point in Time Recovery |
Previous Message | Bruce Momjian | 2004-07-19 03:14:10 | Re: [HACKERS] Point in Time Recovery |