Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!ub!canisius!pavlov
From: pavlov@canisius.UUCP (Greg Pavlov)
Newsgroups: comp.databases
Subject: Re: INGRES (was: Re: Oracle/Ingres Comparison Request)
Message-ID: <3275@canisius.UUCP>
Date: 16 Mar 91 05:59:38 GMT
References: <1698@formtek.UUCP> <1991Mar14.182225.12723@leland.Stanford.EDU>
Distribution: na
Organization: Canisius College, Buffalo N.Y. 14208
Lines: 63

In article <1991Mar14.182225.12723@leland.Stanford.EDU>, chesky@leland.Stanford.EDU (Snehylata Gupta) writes:
> 
> INGRES haas stability problems even on the VMS platform.....  For
> example one consistent problem that we have had with INGRES is the
> handling of a bad database access typically :
> 
>   [ a retrieval query producing a cartesian product ]
> 
> The INGRES developers probably assumed that such queries would not be
> submitted...... 

> When you look at the engine you will see that this query is just hogging
> all the resourcess and not allocating any resources to other users.
> 
> When you have 100+ users on the system and a developer launched such a
> query. You will start getting phone calls within 15-30 min. When you go
> and yell at the developer. Lets say he kills the job. So you expect that
> that would solve all your problems. But wait your problems have just
> begun. Because now INGRES has begun to cleanup after itself. So you sit
> there and watch (I have watched for upto 5-6 hours while this
> continues.) .....
> .....and you are telling them that you have been trying to kill all
> the processes but they are not going away. So you have to shut INGRES
> down completely. Some databases (at least) will be corrupted. 

> However :
> -------
> All the above problems have only when INGRES is misused. INGRES does not
> seem to give much problems if you know what you are doing.
> 
  From our own long, painful hegira thru version 6, I would say that
  you are describing things reasonably accurately but you are not inter-
  preting the symptoms quite correctly.

  First, the cartesian product you showed is NOT the cause of the problem
  in and of itself:  actually, there were various queries and/or actions
  that would cause similar results, e.g., the backend would become "con-
  sumed" by a single process, sometimes an errant one,  sometimes a legit-
  imate one.  INGRES tech people described the mechanics of the bug to us and
  eventually provided a patch that has pretty much cleared it up on our
  platform (DEC RISC).

  Likewise, the cleanup operation you describe was also more generic than
  you describe (on our version, anyway); this also seems to have been
  pretty well cleaned up by now.  Acording to INGRES tech support, earlier
  version 6 releases tended to inappropriately log certain classes of
  transactions, such as initial table creates/loads and secondary index
  generation.  In their words, this "code was removed" from those places
  where it shouldn't have been.
 
  Yah, things are getting better.  At the moment, only four more serious
  bugs to go .... (anybody want to give INGRES a hand with some stable
  btree algorithms ???).

> Maybe I have been overly harsh in my criticism of INGRES's problems but
> as a total system I prefer it to ORACLE and INFORMIX.

  - that was my attitude for a long time.  But it's pretty well gone at
    this point.


    greg pavlov, fstrf, amherst, ny
    pavlov@stewart.fstrf.org