Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend] - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]
Date
Msg-id 36059AD4.6728E312@alumni.caltech.edu
Whole thread Raw
In response to Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]  (Christopher Oliver <oliver@fritz.traverse.net>)
List 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 by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] Re: NOTICE: _outNode: don't know how to print type 715
Next
From: "Thomas G. Lockhart"
Date:
Subject: Re: [HACKERS] Windows NT port of Postgres