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

From Bruce Momjian
Subject Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]
Date
Msg-id 199809210222.WAA16995@candle.pha.pa.us
Whole thread Raw
In response to Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]  (Christopher Oliver <oliver@fritz.traverse.net>)
Responses Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]  (Christopher Oliver <oliver@fritz.traverse.net>)
List pgsql-hackers
> > 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.
>
> 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.  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.
> 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.
>
> > 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.
>
> Even vaccinations require periodic renewal.  The only degree to which
> a test becomes stale is the degree that a feature is completely removed.
>
> > 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}

OK, what do you suggest we do?

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.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.        |

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Windows NT port of Postgres
Next
From: Bruce Momjian
Date:
Subject: Open 6.4 Items