Re: Pause/Resume feature for Hot Standby - Mailing list pgsql-hackers
From | Simon Riggs |
---|---|
Subject | Re: Pause/Resume feature for Hot Standby |
Date | |
Msg-id | 1272985826.4535.2276.camel@ebony Whole thread Raw |
In response to | Re: Pause/Resume feature for Hot Standby (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: Pause/Resume feature for Hot Standby
Re: Pause/Resume feature for Hot Standby |
List | pgsql-hackers |
On Tue, 2010-05-04 at 09:36 -0400, Robert Haas wrote: > On Tue, May 4, 2010 at 4:02 AM, Simon Riggs <simon@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? Robert, This is clearly a response to issues raised about HS and not a new feature. It's also proposed in the most minimal way possible with respect for the current state of release. Why is you think I want to go to beta less quickly than anyone else? I have many other items to work on in the new release also, none of them have been even discussed, again out of respect for the timing and the process. > 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. There hasn't been anything more than a minor bug in weeks, so not really sure how you arrive at that the idea the code needs "stabilising". But even if you think we need "stabilising", how do you propose I do that? What exact action? When people complain, I propose solutions. If you then object that the proposed solution is actually a new feature, that leaves us in a deadlock. There is no evidence that Erik's strange performance has anything to do with HS; it hasn't been seen elsewhere and he didn't respond to questions about the test setup to provide background. The profile didn't fit any software problem I can see. -- Simon Riggs www.2ndQuadrant.com
pgsql-hackers by date: