Tom Lane wrote:
>> 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.
I think you are right.
> 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 agree that it is enough to have a separate pg_finish_wal_segment().
Adding that in your backup script between pg_stop_backup() and tarring
of the archived WAL files would by a simple enough step.
Yours,
Laurenz Albe
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
