Re: [HACKERS] CORBA STATUS

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
undertaking and 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 have to be rewritten for every
ORB. If you want to do this I suggest starting with
ORBit since it is all C and thereby easier to slap
onto PgSQL.

3. Extend postmaster to proxy CORBA requests.
Postmaster could fork of postgres processes
on incoming connections. Postmaster will 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!