I have done some research into slapping
a CORBA interface onto the PgSQL server.
I have looked at ORBit but my findings
seems to apply to most CORBA implementations.
I found that there is a fundamental problem
concerning the difference in process models
in pgsql and the POA (Portable Object Adaptor)
in CORBA implementations.
AFAICS, POA assumes a threaded server while
PgSQL uses a traditional forking model.
I see 3 ways to resolve this:
1. Adapt the PgSQL server to use threads instead of forking. I am not sure we want to do this since it is a major
undertakingand will not help the rock solid stability we expect from a professional RDBMS.
2. Write a Forking Object Adaptor (FOA). Would be a big job but it would benefit other similar projects. A FOA would
haveto be rewritten for every ORB. If you want to do this I suggest starting with ORBit since it is all C and thereby
easierto slap onto PgSQL.
3. Extend postmaster to proxy CORBA requests. Postmaster could fork of postgres processes on incoming connections.
Postmasterwill keep listening and proxying request and responses to/from the postgres process through some kind of
IPC.This will make the postmaster multithreaded and the postgres processes still singlethreaded.
It is doubtful if the gains:
- standard-based protocols
- less code to maintain (?)
justifies the amount of work required.
An easier way out is to, as suggested by others,
implement the CORBA-service outside the server
itself. It will in some cases give some latency
related performance degrading compared to a
in-server implementation.
One effort to do something like that
(and more) is gnome-db. Check out
http://www.gnome.org/gnome-db/
regards,
-----------------
Göran Thyni
On quiet nights you can hear Windows NT reboot!
