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 1153841842.2592.579.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  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 2006-07-25 at 11:07 -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Where are we on these TODO items:
> 
> >           o Allow point-in-time recovery to archive partially filled
> >             write-ahead logs [pitr]
> 
> I believe we'd agreed that the necessary infrastructure for this is
> just a function to tell the current WAL segment name and offset.

Not that I remember. That was just a proposal for backpatching to
8.1/8.0 so that it would be easier to cope with PITR at those releases.

> >           o Automatically force archiving of partially-filled WAL files when
> >             pg_stop_backup() is called or the server is stopped
> 
> I see no need for that to be "automatic".  I'd vote for a simple
> function pg_finish_wal_segment() or something like that, which you
> call just after pg_stop_backup() if you want this behavior.  Trying
> to tie it into pg_stop_backup() will only make things more complicated
> and less flexible.

Putting it into pg_stop_backup was what we previously agreed.

Where is the loss of flexibility?

I need to get this straight because I was actually intending to do this
for 8.2, i.e. next few days.

--  Simon Riggs              EnterpriseDB   http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: Better name/syntax for "online" index creation
Next
From: "Dave Page"
Date:
Subject: Re: root/administartor user check option.