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

From Simon Riggs
Subject Re: Forcing current WAL file to be archived
Date
Msg-id 1153842583.2592.595.camel@holly
Whole thread Raw
In response to Re: Forcing current WAL file to be archived  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Forcing current WAL file to be archived  (Bruce Momjian <bruce@momjian.us>)
Re: Forcing current WAL file to be archived  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 2006-07-25 at 11:31 -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Forcing current WAL file to be archived
Next
From: Tom Lane
Date:
Subject: Re: Forcing current WAL file to be archived