Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]

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. |

In response to

Responses

Browse pgsql-hackers by date

  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