From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 15:49:43 |
Message-ID: | 1153842583.2592.595.camel@holly |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2006-07-25 at 11:31 -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > For example, if you do pg_stop_backup(), in what cases would you not
> > also call pg_finish_wal_segment()? I can't think of one.
>
> I can't see why you would need to, unless your intention is not to run
> PITR at all but only to make a filesystem backup instead of using
> pg_dump.
If thats all you want you can set
archive_command = 'echo %f %p > /dev/null'
> Normally you'd be running a continuing archival process and
> there's no particular need to force the current WAL segment off to
> archive at that exact instant.
That's exactly the point of contention. When we originally completed
PITR we thought that was acceptable. It isn't and many people have stuck
pins in effigies of me since then. :-/
> 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.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Csaba Nagy | 2006-07-25 15:52:17 | Re: Forcing current WAL file to be archived |
Previous Message | Bruce Momjian | 2006-07-25 15:48:15 | Re: Forcing current WAL file to be archived |