Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]
От | Thomas G. Lockhart |
---|---|
Тема | Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend] |
Дата | |
Msg-id | 36059AD4.6728E312@alumni.caltech.edu обсуждение исходный текст |
Ответ на | 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]
|
Список | pgsql-hackers |
> > > My I, a humble newcomer, make a suggestion? Should we place any > > > legitimate query set we've discovered to cause crashes into our > > > regression suite? > We keep the current crash items until they are fixed during beta. > They go on to the current items list. If they don't get fixed, they > are moved to the TODO list, where you will see the unfixed ones > mentioned. The regression suite should reasonably be expected to pass on a system which has an "as good as it gets" installation. We haven't been very good about moving new features and fixed breakage _into_ the regression suite once it is fixed, but we shouldn't move known breakage into the regression suite. Bruce keeps the ToDo list, and does a good job of filtering problem statements down to the one line per problem allowed in that list. Occasionally it would be helpful to carry along more verbiage to describe a problem, but that would open a can of worms in making the ToDo list unreadable because it is too verbose. I'm not sure of the best way to document these kinds of problem statements. If we generate a "catchall file" of queries which crash, it runs the great risk of becoming stale and useless. To undertake this we probably need a volunteer from the developer's list who would be willing to babysit this file of problem queries, and even better to make sure that new features move from this file to the regression test. Hmm, we could have a "breakage" regression suite which could illustrate broken features and which would fail if a broken feature is fixed. Would be most effective if we had a volunteer maintainer for it... btw, for many kinds of problem statements (such as the one which started this thread), the problem was not known until it was mentioned. It's likely to be picked up by one of the active developers/maintainers, 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... We were all newcomers to Postgres at one time or another, and ended up contributing in areas in which we had the most interest. There is always room for more contributors, especially in areas which aren't at the top of someone else's list since that area is probably not getting covered at all. - Tom
В списке pgsql-hackers по дате отправления: