On Wed, 2002-08-07 at 23:41, Tom Lane wrote:
> "J. R. Nield" <jrnield@usol.com> writes:
> > The xlog code must allow us to force an advance to the next log file,
> > and truncate the archived file when it's copied so as not to waste
> > space.
>
> Uh, why? Why not just force a checkpoint and remember the exact
> location of the checkpoint within the current log file?
If I do a backup with PITR and save it to tape, I need to be able to
restore it even if my machine is destroyed in a fire, and all the logs
since the end of a backup are destroyed. If we don't allow the user to
force a log advance, how will he do this? I don't want to copy the log
file, and then have the original be written to later, because it will
become confusing as to which log file to use.
Is the complexity really that big of a problem with this?
>
> When and if you roll back to a prior checkpoint, you'd want to start the
> system running forward with a new xlog file, I think (compare what
> pg_resetxlog does). But it doesn't follow that you MUST force an xlog
> file boundary simply because you're taking a backup.
>
> > This complicates both the recovery logic and XLogInsert, and I'm trying
> > to kill the "last" latent bug in that feature now.
>
> Indeed. How about keeping it simple, instead?
>
> regards, tom lane
>
--
J. R. Nield
jrnield@usol.com