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
