Re: [HACKERS] Point in Time Recovery - Mailing list pgsql-patches
From | Bruce Momjian |
---|---|
Subject | Re: [HACKERS] Point in Time Recovery |
Date | |
Msg-id | 200407190321.i6J3LVY08349@candle.pha.pa.us Whole thread Raw |
In response to | Re: [HACKERS] Point in Time Recovery (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: [HACKERS] Point in Time Recovery
|
List | pgsql-patches |
Tom Lane wrote: > 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.) 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@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
pgsql-patches by date: