Re: Issues Outstanding for Point In Time Recovery (PITR)

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(at)usol(dot)com]
> Sent: Wednesday, July 17, 2002 8:13 PM
> To: richt(at)multera(dot)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(at)usol(dot)com
>
>
>
>
--
J. R. Nield
jrnield(at)usol(dot)com