Streaming replication, and walsender during recovery
in [PgSql]
|
From: Simon Riggs on 28 Jan 2010 11:22 On Thu, 2010-01-28 at 10:48 -0500, Tom Lane wrote: > Fujii Masao <masao.fujii(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 28 Jan 2010 11:41 Simon Riggs <simon(a)2ndQuadrant.com> writes: > 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. FWIW, I don't agree with that prioritization in the least. Cascading is something we could leave till 9.1, or even later, and hardly anyone would care. We have much more important problems to be spending our effort on right now. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 28 Jan 2010 12:09 On Thu, Jan 28, 2010 at 11:41 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Simon Riggs <simon(a)2ndQuadrant.com> writes: >> 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. > > FWIW, I don't agree with that prioritization in the least. Cascading > is something we could leave till 9.1, or even later, and hardly anyone > would care. We have much more important problems to be spending our > effort on right now. I agree. According to http://wiki.postgresql.org/wiki/Hot_Standby_TODO , the only must-fix issues that remain prior to beta are (1) implementing the new VACUUM FULL for system relations, and (2) some documentation improvements. It's a little early to be worrying about docs, but shouldn't we be trying to get the VACUUM FULL problems cleaned up first, and then look at what else we have time to address? As regards the remaining items for streaming replication at: http://wiki.postgresql.org/wiki/Streaming_Replication#v9.0 ....ISTM the most important issues are (1) fixing win32 and (2) adding a message type header, followed by (3) fixing pg_xlogfile_name() and (4) redefining smart shutdown in standby mode. If we fix the must-fix issues first, we can still decide to delay the release to fix the would-like-to-fix issues, or not. The other way around doesn't work. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 28 Jan 2010 12:42 On Thu, 2010-01-28 at 12:09 -0500, Robert Haas wrote: > I agree. According to > http://wiki.postgresql.org/wiki/Hot_Standby_TODO , the only must-fix > issues that remain prior to beta are (1) implementing the new VACUUM > FULL for system relations, and (2) some documentation improvements. > It's a little early to be worrying about docs, but shouldn't we be > trying to get the VACUUM FULL problems cleaned up first, and then look > at what else we have time to address? Please don't confuse different issues. The fact that I have work to do still is irrelevant to what other people should do on other features. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 28 Jan 2010 12:45
On Thu, 2010-01-28 at 11:41 -0500, Tom Lane wrote: > Simon Riggs <simon(a)2ndQuadrant.com> writes: > > 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. > > FWIW, I don't agree with that prioritization in the least. Cascading > is something we could leave till 9.1, or even later, and Not what you said just a few days ago. > hardly anyone would care. Unfortunately, I think you're very wrong on that specific point. > We have much more important problems to be spending our > effort on right now. I'm a little worried the feature set of streaming rep isn't any better than what we have already. If we're going to destabilise the code, we really should be adding some features as well. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |