Re: Forcing current WAL file to be archived - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Forcing current WAL file to be archived
Date
Msg-id 11661.1153843843@sss.pgh.pa.us
Whole thread Raw
In response to Re: Forcing current WAL file to be archived  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Forcing current WAL file to be archived
List pgsql-hackers
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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Forcing current WAL file to be archived
Next
From: Hannu Krosing
Date:
Subject: Re: Forcing current WAL file to be archived