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

Fri, 16 Jul 2004 12:16:44 +0200
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>
Re: Point in Time Recovery
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> 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

Right, but I think Bruce's point is that it is far too easy to get those
things wrong; especially point 2 for which a straight tar dump will
simply not contain the information you need to determine what is a safe
stopping point.

I agree with Bruce that we should have some mechanism that doesn't rely
on the DBA to get this right.  Exactly what the mechanism should be is
certainly open for discussion...

			regards, tom lane

Fri, 16 Jul 2004 09:37:19 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Point in Time Recovery 
> "Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> > 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
> 
> Right, but I think Bruce's point is that it is far too easy to get those
> things wrong; especially point 2 for which a straight tar dump will
> simply not contain the information you need to determine what is a safe
> stopping point.
> 
> I agree with Bruce that we should have some mechanism that doesn't rely
> on the DBA to get this right.  Exactly what the mechanism should be is
> certainly open for discussion...

Right.  I am wondering what process people would use to backup
pg_control first?  If they do:

	tar -f $TAPE ./global/pg_control .

They will get two copies or pg_control, the early one, and one as part
of the directory scan.  On restore, they would restore the early one,
but the directory scan would overwrite it.  I suppose they could do:

	cp global/pg_control global/pg_control.backup
	tar -f $TAPE .

then on restore once all the files are restored move the
pg_control.backup to its original name.  That gives us the checkpoint
wal/offset but how do we get the start/stop information.  Is that not
required?  Maybe we should just have a start/stop server-side functions
that create a file in the archive directory describing the start/stop
counters and time and the admin would then have to find those values.
Why are the start/stop wal/offset values needed anyway?  I know why we
need the checkpoint value.  Do we need a checkpoint after the archiving
starts but before the backup begins?

Also, when you are in recovery mode, how do you get out of recovery
mode, meaning if you have a power failure, how do you prevent the system
from doing another recovery?  Do you remove the recovery.conf file?

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

Fri, 16 Jul 2004 10:27:43 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Point in Time Recovery
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Also, when you are in recovery mode, how do you get out of recovery
> mode, meaning if you have a power failure, how do you prevent the system
> from doing another recovery?  Do you remove the recovery.conf file?

I do not care for the idea of a recovery.conf file at all, and have been
intending to look to see what we'd need to do to not have one.  I find
it hard to believe that there is anything one would put in it that is
really persistent state.  The above concern shows why it shouldn't be
treated as a persistent configuration file.

			regards, tom lane

Fri, 16 Jul 2004 10:48:22 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Point in Time Recovery 
On Fri, 2004-07-16 at 15:27, Bruce Momjian wrote:

> Also, when you are in recovery mode, how do you get out of recovery
> mode, meaning if you have a power failure, how do you prevent the system
> from doing another recovery?  Do you remove the recovery.conf file?

That was the whole point of the recovery.conf file:
it prevents you from re-entering recovery accidentally, as would occur
if the parameters were set in the normal .conf file.

Best Regards, Simon Riggs


Fri, 16 Jul 2004 17:56:37 +0100
Simon Riggs <simon@2ndquadrant.com>
Re: Point in Time Recovery