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
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 |