Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]

> If the queries which produce the problem are not exotic, then why
> should they not go there? I would prefer a regression that took half
> an hour or longer on modern hardware yet screened the code to a degree
> that I could have reasonable faith in an installation if it passed the
> regression.

Well, we shouldn't get caught up in semantics, but in this case it gets
to the heart of the intent: the regression test is designed to test if
known-good features are still good and behavior on one installation
matches behavior on another, not to ensure or document that known-bad
features are still bad.

Another test (or other docs, or ??) might be a good idea, and we could
certainly benefit from it I'm sure, but the regression test is not where
that should go.

As you point out above, "I could have reasonable faith in an
installation if it passed the regression", and that is true; if the
regression test passes you can have reasonable faith that your
installation is a good Postgres installation. It won't ensure that your
Postgres installation does everything you want it to, and no test can do
that :)

> As it stands, I had to back off of a recommendation even
> with a promise of my maintenance. I'll reiterate that quite common
> queries are causing NULL pointers to get chased even in non-beta code.

Sure. And thanks for pointing it out. And we'll work on it. And we'll be
glad to accept patches from any source which would fix it immediately.

> When someone snoozes, our tests should alert us to that. I think to
> ensure reliability, the regression must be as complete as possible.
> It should work as an acceptance criterion. As it stands, it doesn't
> test severely enough for much if any confidence in deployment.

?? See above. The regression test does exactly what is intended for it.
If there is another kind of test you would like to propose or
contribute, we'd certainly consider it.

> > though since it has been broken forever it doesn't count as a
> > "must-fix" bug and may not make it into the v6.4 release. But it
> > does count as a "should-fix" bug, and it's possible it could be
> fixed for v6.4...
> Seg faults in the backend for standard queries would count as must-fix
> from my view. The only justification for failure in the non-exotic
> queries is that we are ignorant of the bug's existence. Once we are
> aware, fixing these should become priority one.
>
> \begin{soapbox}
>
> At the very time ESR is lecturing the software community that open-
> source is the way things should work, we have the opportunity to
> support or refute his claims based on how seriously we take repair
> and maintenance where non-exotic queries induce damage and failure.
>
> Think about the free UNIX-like kernels. They are now gaining accept-
> ance mostly because they keep running even when folk beat on them.
> We have glass jaws, and it shows. Let's take the required steps to
> firm them up.
>
> \end{soapbox}

Well, that's all well and good. The way Open Source works is that
_everyone_ has the tools available to them to make the product better,
and some folks will use those tools to contribute back. Not everyone has
to or can, and there is a role for those offering encouragement as well
as those offering actual code. But Open Source doesn't happen without
user participation, and the next version is never the last version.

Postgres has undergone a tremendous evolutionary improvement over the
last two years, and it's actually encouraging that we get darn few
reports of problems with simple (though uncommon) cases such as yours.

Don't panic: yours is the first problem report of this failure, and if
you're disappointed in the response please remember that you brought it
up only three days ago. And that you've gotten two or three responses
from the "support team" since then. And we haven't asked for money. All
in all, a great bargain :)

Regards.

- Tom