Received: from villa.bildbasen.se (villa.bildbasen.kiruna.se [193.45.225.97]) by hub.org (8.9.3/8.9.3) with SMTP id MAA57983 for ; Tue, 9 Nov 1999 12:16:07 -0500 (EST) (envelope-from goran@kirra.net) Received: (qmail 11942 invoked from network); 9 Nov 1999 17:15:10 -0000 Received: from a212.dial.kiruna.se (HELO kirra.net) (193.45.238.28) by villa.bildbasen.kiruna.se with SMTP; 9 Nov 1999 17:15:10 -0000 Sender: goran Message-ID: <3828569A.3BE41F94@kirra.net> Date: Tue, 09 Nov 1999 18:15:06 +0100 From: Goran Thyni Organization: kirra.net X-Mailer: Mozilla 4.6 [en] (X11; U; Linux 2.2.13 i586) X-Accept-Language: sv, en MIME-Version: 1.0 To: mail-list@molnir.com CC: pgsql-interfaces@postgreSQL.org, pgsql-hackers@postgreSQL.org Subject: Re: [HACKERS] CORBA STATUS References: <001401bf2a53$23d22510$dea993c3@tosh3> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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!