Re: Streaming replication, and walsender during recovery
От | Simon Riggs |
---|---|
Тема | Re: Streaming replication, and walsender during recovery |
Дата | |
Msg-id | 1264705998.24669.11552.camel@ebony обсуждение исходный текст |
Ответ на | Re: Streaming replication, and walsender during recovery (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Streaming replication, and walsender during recovery
Re: Streaming replication, and walsender during recovery Re: Streaming replication, and walsender during recovery |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: