Re: Point in Time Recovery

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Point in Time Recovery
Date: 2004-07-13 23:54:05
Message-ID: 1089762845.17493.3417.camel@stromboli
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers pgsql-patches

On Wed, 2004-07-14 at 00:28, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > OK, but procedurally, how do you correlate the start/stop time of the
> > tar backup with the WAL numeric file names?
>
> Ideally the procedure for making a backup would go something like:
>
> 1. Inquire of the server its current time and the WAL position of the
> most recent checkpoint record (which is what you really need).
>
> 2. Make the backup.
>
> 3. Inquire of the server its current time and the current end-of-WAL
> position.
>
> 4. Record items 1 and 3 along with the backup itself.
>
> I think the current theory was you could fake #1 by copying pg_control
> before everything else, but this doesn't really help for step #3, so
> it would probably be better to add some server functions to get this
> info.
>

err...I think at this point we should review the PITR patch....

The recovery mechanism doesn't rely upon you knowing 1 or 3. The
recovery reads pg_control (from the backup) and then attempts to
de-archive the appropriate xlog segment file and then starts rollforward
from there. Effectively, restore assumes it has access to an infinite
timeline of logs....which clearly isn't the case, but its up to *you* to
check that you have the logs that go with the backups. (Or put another
way, if this sounds hard, buy some software that administers the
procedure for you). That's the mechanism that allows "infinite
recovery".

In brief, the code path is as identical as possible to the current crash
recovery situation...archive recovery restores the files from archive
when they are needed, just as if they had always been in pg_xlog, in a
way that ensures pg_xlog never runs out of space.

Recovery ends when: it reaches the recovery target you specified, or it
runs out of xlogs (first it runs out of archived xlogs, then tries to
find a more recent local copy if there is one).

I think the current theory was you could fake #1 by copying pg_control
> before everything else, but this doesn't really help for step #3, so
> it would probably be better to add some server functions to get this
> info.

Not sure what you mean by "fake"....

Best Regards, Simon Riggs

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Gaetano Mendola 2004-07-13 23:56:56 Re: Slony NG
Previous Message Tom Lane 2004-07-13 23:28:21 Re: Point in Time Recovery

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2004-07-14 00:30:45 Re: Release planning (was: Re: Status report)
Previous Message Tom Lane 2004-07-13 23:28:21 Re: Point in Time Recovery

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2004-07-14 01:19:37 Re: serverlog rotation/functions
Previous Message Tom Lane 2004-07-13 23:28:21 Re: Point in Time Recovery