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

Hi,

sorry for interference,
this is a very good topic for discussing and in spite of some stress
it indicates Postgres are really coming into production and most
important question becomes a stability.

On Mon, 21 Sep 1998, Christopher Oliver wrote:

> Date: Mon, 21 Sep 1998 01:34:08 -0400
> From: Christopher Oliver <oliver@fritz.traverse.net>
> To: Bruce Momjian <maillist@candle.pha.pa.us>
> Cc: pgsql-hackers@postgreSQL.org
> Subject: Re: [sferac@bo.nettuno.it: Re: [HACKERS] BUG: NOT boolfield kills backend]
>
> > OK, what do you suggest we do?
>
> What I'm basically suggesting is to increase the stringency of the
> regression suite.  Several posters supported my idea of keeping crash-
> ing tests around.  I think they should stick around indefinitely.
> I.e. 6.4 BETA1 has some pointer errors that turn up as crashes in the
> query optimizer.  They seem to be of the form CLAUSE AND (CLAUSE OR
> CLAUSE) or the same with the disjunction and conjunction reversed.
> This sort of construct or the crashing negation construct someone
> complained of earlier are likely to arise in real life.  It's not
> unreasonable therefore that tests for such patterns be added to the
> regression suite.  I.e. we collect the past queries from the real
> world that crash our system with a mind to validate the software

I'm using postgres in commecrcial applications  since beginning of 1995 and
certainly without home-made test-suite I couldn't do that.
And I put new version into production only if my test-sute passes
for me on specific machine and works at least month.
Sometimes it works but I didnt' satisfied by speed and I'm looking
for workaround ( robust workaround ). I would be happy if someone
could works on general test suite which cover my specific data,
operational system and environment and I would prefer to run regression tests
for a 30 minutes, one hour or more if it would guarantee my applications will
run ok, but I understand how different may be data, OSes and especially
appl. environment. i.e. fast developing Linux, compilers, locale, libc etc...

> should they recur.  You mentioned that your old code somehow crept
> into oid8types(), so it isn't simply a waste of testing time to
> test against "old friends."  Also, this defends against someone down
> the road getting some "bright" idea that was discarded in the past
> on grounds of workability or soundness.  Fundamentally, I'm advocating
> defensive coding as base practice, and I think perhaps a strong valid-
> ation suite might be a step toward enforcing this.  I might also advo-
> cate that authors show the discipline of running a full regression
> before submitting to the code base.  This is mostly a cultural thing.
> I think it was Jolly Chen who said that while he hadn't lost any
> data, he was glad the system wasn't managing his payroll.  Imagine it
> IS your bank balance riding on the lines of code you write.  I don't
> think I'm being as draconian as some software engineering folk, but
> I think these sort of steps might help PGSQL move from strength to
> strength.
>
> --
> Christopher Oliver                     Traverse Internet
> Systems Coordinator                    223 Grandview Pkwy, Suite 108
> oliver@traverse.net                    Traverse City, Michigan, 49684
>   "What good is a can of worms if you never open it?"  -Bob Arning
>

_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83