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 pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026