Robert Haas wrote: > OK, but... there will always be things that will bring down the > stand-by, just as there will always be things that can bring down the > primary. A bucket of ice-water will probably do it, for example. I > mean, it would be great to make it better, but is it so bad that we > can't postpone that improvement to a follow-on patch?
We're not talking about a bucket of ice-water. We're talking about issuing SELECTs to a lot of different tables in a single transaction. > Only one or two of the items on your list of additional TODOs > seem like they might fall into category (2), and none of them appear > to fall into category (1). At least the b-tree vacuum bug could cause incorrect answers, even though it would be extremely hard to run into it in practice. > I predict that if we commit a basic version of this with some annoying > limitations for 8.5, people who need the feature will start writing > patches to address some of the limitations. No one else is going to > undertake any serious development work as long as this remains outside > the main tree, for fear of everything changing under them and all > their work being wasted. I would like this feature to be as good as > possible, but I would like to have it at all more. Agreed. Believe me, I'd like to have this committed as much as everyone else. But once I do that, I'm also committing myself to fix all the remaining issues before the release. The criteria for committing is: is it good enough that we could release it tomorrow with no further changes? Nothing more, nothing less. We have *already* postponed a lot of nice-to-have stuff like the functions to control recovery. And yes, many of the things I listed in the TODO are not must-haves and we could well release without them. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers