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

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(at)fritz(dot)traverse(dot)net>
> To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
> Cc: pgsql-hackers(at)postgreSQL(dot)org
> Subject: Re: [sferac(at)bo(dot)nettuno(dot)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(at)traverse(dot)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(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83