Re: Streaming replication, and walsender during recovery
От | Simon Riggs |
---|---|
Тема | Re: Streaming replication, and walsender during recovery |
Дата | |
Msg-id | 1264695730.24669.10882.camel@ebony обсуждение исходный текст |
Ответ на | Re: Streaming replication, and walsender during recovery (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Streaming replication, and walsender during recovery
Re: Streaming replication, and walsender during recovery |
Список | pgsql-hackers |
On Thu, 2010-01-28 at 10:48 -0500, Tom Lane wrote: > Fujii Masao <masao.fujii@gmail.com> writes: > > How about just making a restore_command copy the WAL files as the > > normal one (e.g., 0000...) instead of a pg_xlog/RECOVERYXLOG? > > Though we need to worry about deleting them, we can easily leave > > the task to the bgwriter. > > The reason for doing it that way was to limit disk space usage during > a long restore. I'm not convinced we can leave the task to the bgwriter > --- it shouldn't be deleting anything at that point. I think "bgwriter" means RemoveOldXlogFiles(), which would normally clear down files at checkpoint. If that was added to the end of RecoveryRestartPoint() to do roughly the same job then it could potentially work. 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'm keen to allow cascading in 9.0. If you pull both synch rep and cascading you're not offering much that isn't already there. -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: