From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | oliver(at)fritz(dot)traverse(dot)net (Christopher Oliver) |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, techguys(at)traverse(dot)net |
Subject: | Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend] |
Date: | 1998-09-21 02:22:50 |
Message-ID: | 199809210222.WAA16995@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(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. |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-09-21 02:28:14 | Open 6.4 Items |
Previous Message | Bruce Momjian | 1998-09-21 02:20:16 | Re: [HACKERS] current- crash |