J. R. Nield wrote: > I will do something like this, but reserve 16 bytes for it just in case > we change our minds. It needs to be different among systems on the same > machine, so there needs to be a time value and a pseudo-random part as > well. Also, 'hostname' will likely be the same on many machines > (localhost.localdomain or similar). > > The only reason I bothered with UUID's before is because they have a > standard setup to make the possibility of collision extremely small, and > I figured replication will end up using it someday.
Sure. Problem is, we support so many platforms that any trickery is a problem. If they can change it in postgresql.conf, that should be sufficient. > Hot backup read/write requires that we force an advance in the logfile > segment after the backup. We need to save all the logs between backup > start and completion. Otherwise the files will be useless as a > standalone system if the current logs somehow get destroyed (fire in the > machine room, etc.). > > The way I would do this is: > > create a checkpoint > do the block-by-block walk of the files using the bufmgr > create a second checkpoint > force the log to advance past the end of the current segment > save the log segments containing records between the > first & second checkpont with the backup Sounds good. > Then if you restore the backup, you can recover to the point of the > second checkpoint, even if the logs since then are all gone. Good, you put the logs that happened during the backup inside the same backup, make it consistent. Makes sense. > Right now the log segment size is fixed, so this means that we'd waste > 8MB of log space on average to do a backup. Also, the way XLOG reads > records right now, we have to write placeholder records into the empty > space, because that's how it finds the end of the log stream. So I need > to change XLOG to handle "skip records", and then to truncate the file > when it gets archived, so we don't have to save up to 16MB of zeros. > > Also, if archiving is turned off, then we can't recycle or delete any > logs for the duration of the backup, and we have to save them. > > So I'll finish the XLOG support for this, and then think about the > correct way to walk through all the files. Sounds like a good plan. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
