Re: [HACKERS] More CORBA and PostgreSQL]

On Fri, Nov 13, 1998 at 09:00:14AM -0400, The Hermit Hacker wrote:

On Fri, 13 Nov 1998, Michael Robinson wrote:

- The ORBit sources appear to be LGPL'ed, which means they can be linked to
PostgreSQL without poisoning the BSD license.

Mico is also LGPL'd for the libraries...

I also have bad news to report.

- Most of the CORBA functionality that PostgreSQL would rely on is currently
unimplemented in ORBit.

I don't know what is implemented, but check out:

http://www.vsb.cs.uni-frankfurt.de/~mico

They "claim" a completely 2.2 Corba implementation...

- While CORBA provides a very disciplined interface for allowing different
object implementations (e.g. Python and PostgreSQL) to share the same address
space and execution context safely and efficiently, the PostgreSQL backend
doesn't seem ready for it. In particular, it doesn't appear to be thread
safe. It may not even be reentrant, from what I can tell. And, if a backend
process is not punctual about reading cache synchronization messages out of
the IPC queue, it appears that excessive cache invalidation would hurt
performance.

Hrmmm...does this mean that we are going to have to move towards a
threaded model vs forked? Or is it just going to require some major code
cleanups for the 'thread safe/reentrant' as aspect?

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

OK, here as another viewpoint.

Don't even think about MICO. Its design goals are pedagical. It is
very slow, very, very compiler hungry, and has no collocation
optimization.

ILU is multi-language, and GPL uncontaminated. It seems to be
under development by a very small team. They just released the
13th alpha. a12 to a13 was roughly a year. You need to be
prepared for relatively slow code development, with code changes
visible only at release points.

ORBit is C only, which was very important to the GNOME group.
Having worked in C under ILU, I have come to think this a
large mistake; working to overcome the hysterisis gets to be
very irritating, and checking for exceptions is a real pain.
Also, ORBit is a bare ORB with no services and not much
documentation.

Another option I have seen no discussion of is TAO. Fast, aggresive
development. CVS available, fair service support. Built on underlying
library. Essentially C++ only (some Java support). See
http://www.cs.wustl.edu/~schmidt/. This is also not GPL.

I am assuming that you have looked at OmniORB and rejected it for
GPL reasons. If not, you should also consider it.

Finally, I am not sure about the threading. It may be easier to think
about caching less and more about quick startup. It is not clear to
me that having a thread-safe agent managing a pool of forked backends
is inherently that much slower, and in many applications (like a
Web fronted one) is clearly a great improvement in terms of
memory usage. Of course, if cache invalidation is such a large
performance loss, the agent could attempt to minimize the effects
by employing user affinity, or even better, if parsinng is easy
enough, by relation affinity.

What I would find intereting about this appoach has not been touched
on. It should make building a distributed database very easy.

Ah well, I don't have the time, and maybe not the talent to do the
work, so I will shut up and let you guys get back to the very well
done task of enhancing postgresql.

Thanks

Jim

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

----- End forwarded message -----