Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Nov 16, 2009 at 11:07 AM, Kevin Grittner > <kevin.gritt...@wicourts.gov> wrote: >> Tom Lane wrote: >> >>> I agree with Heikki that it would be better not to commit as long >>> as any clear showstoppers remain unresolved. >> >> I agree that it would be better not to commit as long as any of the >> following are true: >> >> (1) There are any known issues which would break things for >> clusters *not using* hot standby. >> >> (2) There isn't an easy way for to disable configuration of hot >> standby. >> >> (3) There is significant doubt that the vast majority of the patch >> will be useful in the eventually-enabled final solution. >> >> If none of these are true, I'm not sure what the down side of a >> commit is. > > Well, I think you wouldn't want to commit something that enabled Hot > Standby but caused Hot Standby queries to give wrong answers, or > didn't even allow some/all queries to be executed. That's fairly > pointless, and might mislead users into thinking we had a feature > when we really didn't. I might. Based on my project management experience and the tone of the posts on this feature, I suspect that there would be benefit to committing the code -- even if the ability to enable it was commented out. For starters, I suspect that most people won't be using it, so the most important thing for most users is that the patch breaks nothing when the feature is not configured. Also, if we have high confidence that the vast majority of this code will eventually be committed, and likely in 8.5, the sooner it is what people work against, the less likely that a late change will destabilize something. Having made that point, I'm happy to leave it to Heikki's judgment; it's definitely not something I care enough about to argue at any length.... -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
