On Fri, 2010-04-30 at 13:58 -0400, Bruce Momjian wrote:
> Robert Haas wrote:
> > On Fri, Apr 30, 2010 at 1:39 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > > Robert Haas wrote:
> > >> On Fri, Apr 30, 2010 at 12:22 PM, Bruce Momjian <bruce@momjian.us> wrote:
> > >> > Tom Lane wrote:
> > >> >> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> > >> >> > Tom Lane wrote:
> > >> >> >> If you aren't archiving then there's no guarantee that you'll still have
> > >> >> >> a continuous WAL series starting from the start of the backup.
> > >> >>
> > >> >> > I wasn't really thinking of this use case, but you could set
> > >> >> > wal_keep_segments "high enough".
> > >> >>
> > >> >> Ah. ?Okay, that seems like a workable approach, at least for people with
> > >> >> reasonably predictable WAL loads. ?We could certainly improve on it
> > >> >> later to make it more bulletproof, but it's usable now --- if we relax
> > >> >> the error checks.
> > >> >>
> > >> >> (wal_keep_segments can be changed without restarting, right?)
> > >> >
> > >> > Should we allow -1 to mean "keep all segments"?
> > >>
> > >> If that's what you want to do, use archive_mode.
> > >
> > > Uh, I assume that will require me to store the WAL files somewhere else,
> > > rather than keeping them in /pg_xlog, which I thought was the goal. ?Am
> > > I missing something?
> >
> > Well, one of us is. Why would you want to retain all of your WAL logs
> > in pg_xlog forever?
>
> Well, this email thread mentioned a case where you needed to increase
> wal_keep_segments to a sufficiently-high value, and of course figuring
> out such a value is harder than just having a way of turning off
> recycling with -1.
I think the only sensible setting is "as big as my (available) disk
space". Any higher and you're going to crash, any lower and you'll
invalidate your backup for no reason.
-1 emulates current behaviour, BTW
Still think we should rename it, in which case 0 is same as "no
maximum".
-- Simon Riggs www.2ndQuadrant.com
