Re: Issues Outstanding for Point In Time Recovery (PITR) - Mailing list pgsql-hackers

Richard:

I can't quite follow this; maybe you sent a draft by accident. If you
want to post a patch against 7.2.1, or even better against HEAD in CVS,
that would be great. Or if you'd rather point me to your source online,
that would be good too.

I just want to clarify though: is this work released to the PostgreSQL
Development group by Progress and Multera, or do they still claim
copyright interest in it?

Regards,J.R. Nield


On Thu, 2002-07-18 at 12:56, Richard Tucker wrote:
> 
> 
> -----Original Message-----
> From: J. R. Nield [mailto:jrnield@usol.com]
> Sent: Wednesday, July 17, 2002 8:13 PM
> To: richt@multera.com
> Cc: Bruce Momjian
> Subject: RE: [HACKERS] Issues Outstanding for Point In Time Recovery
> (PITR)
> 
> 
> On Wed, 2002-07-17 at 19:25, Richard Tucker wrote:
> > Regarding hot backup.  Our implementation of "pg_copy" does a hot backup.
> > It turns off database checkpointing for the duration of the backup.
> Backups
> > all the files of the database cluster up to the wal file currently being
> > logged to.  It then acquires the WalInsertLock lock long enough to backup
> > the current wal file.
> 
> Does it then allow more writes to that WAL file? It would seem like you
> want to advance the log to the next file, so the sysadmin wouldn't have
> to choose which one of log-file number 3 he wants to use at restore.
> 
> > Writes to the wal file are allowed during the backup except for the
> backing of the wal file current when the
> > backup completes.  That is the pg_xlog directory is the last directory to
> be backed up.  The wal_files are backed
> > up in the order they were used.  Continued wal file logging is allowed
> until the backup reaches the current wal
> > file being written to.  To back up this last wal file the WalInsertLock is
> held until the copy of the wal file
> > is complete.  So the backup stops update activity only long enough to copy
> this last 16mb file.
> 
> Also, what do you mean by 'turns off checkpointing'. You have to do a
> checkpoint, or at least flush the buffers, when you start the backup.
> Otherwise how do you know what LSN to start from at restore?
> 
> > The pg_control file also gets backed up.  It contains the point in the log
> at which to begin
> > the redo/roll forward.
> > By not allowing the redo point to advance while the backup goes on means
> that the startup processes' crash
> > recovery code will capture all the changes made to the database cluster
> while the backup was running.
> 
> 
> Anyway: Yes we'd love to see the code.
> 
> > In what form would you like me to send the code to you e.g. as a patch,
> copy our whole source ...
> 
> Since I've pretty-much got create/drop and index stuff working, if your
> code does the rest then we should be good to go.
> 
> ;jrnield
> 
> 
> --
> J. R. Nield
> jrnield@usol.com
> 
> 
> 
> 
-- 
J. R. Nield
jrnield@usol.com