Progress/Multera would release the hot backup/roll forward work to the PostgreSQL Development group. -regards richt
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of J. R. Nield Sent: Thursday, July 18, 2002 2:34 PM To: [EMAIL PROTECTED] Cc: Bruce Momjian; PostgreSQL Hacker Subject: Re: [HACKERS] 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:[EMAIL PROTECTED]] > Sent: Wednesday, July 17, 2002 8:13 PM > To: [EMAIL PROTECTED] > 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 > [EMAIL PROTECTED] > > > > -- J. R. Nield [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
