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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
