Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > On Tue, 2006-07-25 at 11:31 -0400, Tom Lane wrote:
> >> My point here is that forcing the current segment to archive is a
> >> function of whatever your continuous-archiving process is, and it's
> >> not necessarily tied to backups. We should not prejudge when people
> >> want that fairly-expensive function to be invoked.
>
> > The point is until that last WAL file is backed up, the whole backup is
> > useless. It isn't good policy to have a backup's value be contingent on
> > some future event.
>
> You are assuming here that the continuous archiving process is identical
> to the WAL part of the base-backup process. If what you want is an
> identifiable self-contained base backup then you copy off the WAL files
> along with the tar dump; there's no need to force a switch of the
> current WAL file before you copy it.
If you are doing that, I think for consistency you would want a WAL file
that is completely archived, rather than pulling the current one while
it is being written to.
> I don't disagree that in many scenarios the switch is needful. What I'm
> saying is that we should provide a separately accessible function for it.
> PG's PITR support is basically designed as a toolkit that lets you build
> a PITR solution, not as do-everything, one-size-fits-all monolithic
> functionality, and I want to stay in that spirit.
I don't think we want people wiring their own calculator. Sure we can
give them wires and have them do it themselves, but if we can make it
easier for 99% of the cases (with little downside), we should do it.
PITR has become more of a toolkit only because the partial WAL file
writes were not completed in the original implementation. PITR is hard
enough --- we need to make it easier if possible.
-- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
