From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Forcing current WAL file to be archived |
Date: | 2006-07-25 15:54:33 |
Message-ID: | 200607251554.k6PFsX216909@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > On Tue, 2006-07-25 at 11:07 -0400, Tom Lane wrote:
> >> 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 don't see why you think this function should be tied to making a
> backup. There are other reasons for wanting to force a WAL switch
> than that, and there are scenarios in which you don't need a WAL
Yes, that is why we would have a separate function too.
> switch at the end of a backup.
Well, I figured if you just did a backup, you would want a switch in
_most_ cases, and since you just did a backup, I figured an extra WAL
file would be minimal additional overhead.
--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-07-25 15:57:30 | Re: Forcing current WAL file to be archived |
Previous Message | Tom Lane | 2006-07-25 15:53:06 | Re: Forcing current WAL file to be archived |