On Thu, 2010-01-28 at 21:00 +0200, Heikki Linnakangas wrote:
> However, since not every checkpoint is a restartpoint we might easily
> > end up with significantly more WAL files on the standby than would
> > normally be there when it would be a primary. Not sure if that is an
> > issue in this case, but we can't just assume we can store all files
> > needed to restart the standby on the standby itself, in all cases.
> That
> > might be an argument to add a restartpoint_segments parameter, so we
> can
> > trigger restartpoints on WAL volume as well as time. But even that
> would
> > not put an absolute limit on the number of WAL files.
>
> I think it is a pretty important safety feature that we keep all the
> WAL around that's needed to recover the standby. To avoid
> out-of-disk-space situation, it's probably enough in practice to set
> checkpoint_timeout small enough in the standby to trigger
> restartpoints often enough.
Hmm, I'm sorry but that's bogus. Retaining so much WAL that we are
strongly in danger of blowing disk space is not what I would call a
safety feature. Since there is no way to control or restrain the number
of files for certain, that approach seems fatally flawed. Reducing
checkpoint_timeout is the opposite of what you would want to do for
performance.
-- Simon Riggs www.2ndQuadrant.com
