On Tue, May 4, 2010 at 4:02 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > In the original patch I had Pause/Resume feature for controlling > recovery during Hot Standby. It was removed for lack of time.
Well, it's not like we have more time now than we did then. I think we need to postpone this discussion to 9.1. If we're going to start accepting patches for new features, then why should we accept only patches for HS/SR? I have two patches already in the queue that I'd like to see committed and if I thought that there was a chance of getting anything further done for 9.0, there'd be several more. Many other people have patches waiting also, or are holding off development because we are in feature freeze right now. Hot Standby is a great feature, but, I don't see any reason to say that we're going to allow new feature development just for HS but not for anything else. I also think that worrying about fine-tuning HS at this point is a bit like complaining that the jump suits of the crew of the Space Shuttle Challenger were not made of 100% recyclable materials. Just yesterday we had a report of an HS server getting into a state where it failed to shut down properly; and I believe that we never fully resolved the issue of occasional extremely-long spikes in HS response time, either. Heikki just fixed a bug our btree recovery code which is apparently new to 9.0 since he did not backpatch it. I think that getting into a discussion of pausing and resuming recovery, or even the parallel discussion on max_standby_delay, are fiddling with things that, granted, are probably not ideal, and yes, we should improve them in a future release, but they're not what we should be worrying about right now. What I think we SHOULD be worried about right now - VERY worried - is stabilizing the existing Hot Standby code to the point where it won't be an embarrassment to us when we ship it. The rate at which we're finding new problems even with the small number of people who test alpha releases and nightly snapshots suggests to me that we're not there yet. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
