Re: Forcing current WAL file to be archived

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Forcing current WAL file to be archived
Date: 2006-07-25 16:10:43
Message-ID: 11661.1153843843@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2006-07-25 16:13:40 Re: Forcing current WAL file to be archived
Previous Message Hannu Krosing 2006-07-25 16:05:49 Re: Forcing current WAL file to be archived