Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]
От | Christopher Oliver |
---|---|
Тема | Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend] |
Дата | |
Msg-id | 19980921013408.A2690@fritz.traverse.net обсуждение исходный текст |
Ответ на | Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend] (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]
Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend] |
Список | pgsql-hackers |
> 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 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- 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. -- Christopher Oliver Traverse Internet Systems Coordinator 223 Grandview Pkwy, Suite 108 oliver@traverse.net Traverse City, Michigan, 49684 "What good is a can of worms if you never open it?" -Bob Arning
В списке pgsql-hackers по дате отправления: