Re: Forcing current WAL file to be archived

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

In response to

Responses

Browse pgsql-hackers by date

  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