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

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