Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!purdue!haven!vrdxhq!daitc!daitc.daitc.mil
From: jkrueger@daitc.daitc.mil (Jonathan Krueger)
Newsgroups: comp.databases
Subject: Re: Ingres User's Association Meeting
Message-ID: <509@daitc.daitc.mil>
Date: 7 May 89 00:57:04 GMT
References: <3082@tank.uchicago.edu>
Sender: jkrueger@daitc.daitc.mil
Reply-To: jkrueger@daitc.daitc.mil (Jonathan Krueger)
Distribution: usa
Organization: DTIC Special Projects Office (DTIC-SPO), Alexandria VA
Lines: 39

In article <3082@tank.uchicago.edu>, cs_bob@gsbacd writes:
>As far as I'm concerned, if the back end doesn't run on the machine, 
>Ingres doesn't run on the machine. Ingres is supposedly an RDBMS. If
>they can't get you the database engine, I think it's fair to say that
>they can't give you an RDBMS.

Have you heard the phrase "the network is the computer"?  What do you
think it means?  The machine, in this case, consists of a vax, a
network, and one other processor from {sequent, sun, mips, pyramid, .
. .} INGRES runs on the machine.  One configuration of the machine is
to hang terminals off the vax, and disks off the other processor.  RTI
has said they will support this.

>The annoucement you refer to was definitely not made during the Monday
>morning session, nor was the decision 'reached and announced' at the
>conference. We've known about it for a long time - the problem is that
>BSD doesn't support shared memory, and Ingres 6.x requires it.

Please don't confuse previous general discussion on the issue with the
specific progress and public commitments made at the conference.

>(As an
>aside, someone, I think Marty Sprinzen, made a comment to the effect
>'so far, all of our bugs have been coding errors, not architecture errors.'
>This seems to be an architecture error if there ever was one. Does anyone
>else know of another multi-platform DBMS system that REQUIRES shared memory?)

Yes, I know of others.  As does anyone who bothers to get the facts
and report them correctly.

Look, would you care to research different methods of ensuring
atomicity and serializability, support for them in commercially
available operating systems, and their tradeoffs in performance,
development, installation, scalability, portability, multiprocessor
support?  If some technically qualified person (which I am not, by the
way) were to post a summary on this topic, we'd all be most grateful.

-- Jon
--