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
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 |