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

> > OK, what do you suggest we do?
>
> What I'm basically suggesting is to increase the stringency of the
> regression suite. Several posters supported my idea of keeping crash-
> ing tests around. I think they should stick around indefinitely.
> I.e. 6.4 BETA1 has some pointer errors that turn up as crashes in the
> query optimizer. They seem to be of the form CLAUSE AND (CLAUSE OR
> CLAUSE) or the same with the disjunction and conjunction reversed.
> This sort of construct or the crashing negation construct someone
> complained of earlier are likely to arise in real life. It's not
> unreasonable therefore that tests for such patterns be added to the
> regression suite. I.e. we collect the past queries from the real
> world that crash our system with a mind to validate the software
> should they recur. You mentioned that your old code somehow crept

Basically, there are an infinite number of queries that can be sent to
the backend. Even if we test 10 time the current number of queries, we
don't approach the total possible number of queries.

The AND/OR thing you mentioned is a new problem only because we now
use indexes on OR's, which we never did before. It has been found, and
will be fixed very soon.

There may be other problems, but I doubt that one will come return as a
bug again once it is fixed. Some NEW one will.

> into oid8types(), so it isn't simply a waste of testing time to
> test against "old friends." Also, this defends against someone down
> the road getting some "bright" idea that was discarded in the past
> on grounds of workability or soundness. Fundamentally, I'm advocating
> defensive coding as base practice, and I think perhaps a strong valid-
> ation suite might be a step toward enforcing this. I might also advo-

The old code was put back because for some reason, the new code did not
work. No one has told me the diffence between:

int **var

and

int (*var)[]

but that was the fix. The problem is that people want features added
AND more stable code, and we just can't do both.

The old versions like 6.3.2 are around for people who want them, and no
one is suggesting they have to upgrade, but if they want OR indexing,
they will have to take some instability while I get things working
100%.

There are no shortcuts, and I don't see a regression test finding them
that much faster considering the odds that the regression test may not
have the test that shows the failure.

We also have to consider the cost of trying to approach an infinite
number of query possibilities vs. benefit.

> cate that authors show the discipline of running a full regression
> before submitting to the code base. This is mostly a cultural thing.
> I think it was Jolly Chen who said that while he hadn't lost any
> data, he was glad the system wasn't managing his payroll. Imagine it
> IS your bank balance riding on the lines of code you write. I don't
> think I'm being as draconian as some software engineering folk, but
> I think these sort of steps might help PGSQL move from strength to
> strength.

I don't think we can be accused of throwing code into the backend
without considering the consequences. In fact, I think we are more
strict about it than most/any open software project. It is just the
amount of code and complexity, and the infinite query possibilities that
can bite us.

--
Bruce Momjian | 830 Blythe Avenue
maillist(at)candle(dot)pha(dot)pa(dot)us | Drexel Hill, Pennsylvania 19026
http://www.op.net/~candle | (610) 353-9879(w)
+ If your life is a hard drive, | (610) 853-3000(h)
+ Christ can be your backup. |