Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-hackerspgsql-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

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2004-07-19 03:06:33
Subject: CVS compile failure
Previous:From: Greg StarkDate: 2004-07-19 02:44:36
Subject: Re: Escaping metacharacters

pgsql-admin by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group