Re: Point in Time Recovery

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Point in Time Recovery
Date: 2004-07-16 10:16:44
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA40184D152@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > I'm aiming for the minimum feature set - which means we do need to take
> > care over whether that set is insufficient and also to pull any part
> > that doesn't stand up to close scrutiny over the next few days.
>
> As you can see, we are still chewing on NT. What PITR features are
> missing? I assume because we can't stop file system writes during
> backup that we will need a backup parameter file like I described. Is
> there anything else that PITR needs?

No, we don't need to stop writes ! Not even to split a mirror,
other db's need that to be able to restore, but we dont.
We only need to tell people to backup pg_control first. The rest was only
intended to enforce
1. that pg_control is the first file backed up
2. the dba uses a large enough PIT (or xid) for restore

I think the idea with an extra file with WAL start position was overly
complicated, since all you need is pg_control (+ WAL end position to enforce 2.).

If we don't want to tell people to backup pg_control first, imho the next
best plan would be to add a "WAL start" input (e.g. xlog name) parameter
to recovery.conf, that "fixes" pg_control.

Andreas

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2004-07-16 11:02:17 Re: [pgsql-hackers-win32] Weird new time zone
Previous Message Anja Klein 2004-07-16 09:41:59 analyze.c