On Wed, Jun 29, 2011 at 7:11 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> I don't really see how that's any different from what happens now. If
> (for whatever reason) the master is generating WAL faster than a
> streaming standby can replay it, then the excess WAL is going to pile
> up someplace, and you might run out of disk space. Time-delaying the
> standby creates an additional way for that to happen, but I don't
> think it's an entirely new problem.
The only way to control this is with a time delay that can be changed
while the server is running. A recovery.conf parameter doesn't allow
that, so another way is preferable.
I think the time problems are more complex than said. The patch relies
upon transaction completion times, but not all WAL records have a time
attached to them. Plus you only used commits anyway, not sure why.
Some actions aren't even transactional, such as DROP DATABASE, amongst
others. Consecutive records can be hours apart, so it would be
possible to delay on some WAL records but then replay records that
happened minutes ago, then wait hours for the next apply. So this
patch doesn't do what it claims in all cases.
Similar discussion on max_standby_delay covered exactly that ground
and went on for weeks in 9.0. IIRC I presented the same case you just
did and we agreed in the end that was not acceptable. I'm not going to
repeat it. Please check the archives.
So, again +1 for the feature, but -1 for the currently proposed
implementation, based upon review.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services