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:37:22 |
Message-ID: | 1153841842.2592.579.camel@holly |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2006-07-25 at 11:07 -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2006-07-25 15:39:29 | Re: Forcing current WAL file to be archived |
Previous Message | Tom Lane | 2006-07-25 15:34:09 | Re: column-level privilege |