Tom Lane wrote:
>> The point is until that last WAL file is backed up, the whole backup
>> useless. It isn't good policy to have a backup's value be contingent
>> some future event.
> You are assuming here that the continuous archiving process is
> 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
> 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
> saying is that we should provide a separately accessible function for
> PG's PITR support is basically designed as a toolkit that lets you
> 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.

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

Reply via email to