Kernel mods and RTIngres

[Doug Gwyn <gwyn>]

There are really only two important UNIX variants for the near future,
UNIX System V and 4.2BSD.  Both have facilities for database locking,
and UNIX System V now has the /usr/group lockf system call for record
locking.  (I have considered putting this into the 4.3BSD kernel, but
there are several semantic clashes with the 4BSD flock facility and it
is not obvious how to resolve them.)

I even have a user-mode lockf emulation for 4.2BSD; although it isn't
terrific, given the limited abilities of flock, it is adequate for use
(if careful) in making a general-purpose DBMS that would port directly
to UNIX System V.

Commercial UNIX systems like Xenix have provided record-locking support
for a long time now, generally along the lines of lockf.

Even without lockf, UNIX System V IPC can be (and has been) used to
implement reasonable database concurrent access.

I repeat, there are numerous DBMSes commercially available for a wide
variety of UNIX systems that work fine without kernel hacking.  Why is
RTIngres such a conspicuous exception?  Sure, Ingres was developed in
the dark ages, but hasn't RTI had plenty of opportunity to improve it?

P.S.  I am informed that we removed the RTIngres "lock driver" from our
one system that had it installed.  RTIngres was not correctly handling
concurrent update of databases anyway, so the sole reason for the "lock
driver" was invalidated.

P.P.S.  I'm not a database expert (yet), but I can certainly recognize
poor software design when I see it (which is all too often, alas).