Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!emory!gatech!mcnc!beguine!durham!robinson From: robinson@durham.med.unc.edu (Gerard A. Robinson) Newsgroups: comp.databases Subject: Re: status of Ingres Summary: In defense of both... Message-ID: <1557@beguine.UUCP> Date: 8 Nov 90 13:03:19 GMT References: <2987@canisius.UUCP> <2992@canisius.UUCP> Sender: usenet@beguine.UUCP Reply-To: robinson@uncmed.med.unc.edu (Gerard A. Robinson) Organization: UNC-CH School of Medicine, Office of Information Systems Lines: 22 In defense of Mr. Pavlov here, the Sun version of INGRES 6.3 has had significant patches applied to it, some for shared cache problems (more than one database server), some for b-tree corruption crashing the server (which of course caused the b-tree corruption in the first place), some for indefinite hangs where a semaphore gets 'lost in virtual space'. There have been seven patches that I've heard of, six of which we've received (or will, the seventh was actually a patch of a patch, a real son-of-a-patch :-) These are not intrinsically hardware related, as I know that the semaphore and shared cache problems appeared under VAX/VMS as well. Now on the other hand, the DS3100s that I've had to play with seem doubly damned. I have a little, personal program that I always build called 'where' which prints 'whoami@host:/current_directory umask tty=TERM'. Well the DS3100 would compile this program fine, and run it well, as long as the directory was an even number of characters in length. An odd number? Core dump. So by doubly damned I mean: 1st, its a RISC architecture chip with more restrictive data alignment problems (SPARC systems also exhibit these restrictions), and 2nd, its done with little-endian data types (which to my knowledge other MIPS user/makers *don't* use). But on the other hand, INGRES version 5 does seem quite stable on it now. More later perhaps ... Gerard Robinson