Re: I just got it: PostgreSQL Application Server -- a new project. - Mailing list pgsql-hackers

From Thomas Hallgren
Subject Re: I just got it: PostgreSQL Application Server -- a new project.
Date
Msg-id thhal-0ZqOnAf8yTtsG1ynWSHZ2RDLQ+FlfJL@mailblocks.com
Whole thread Raw
In response to Re: I just got it: PostgreSQL Application Server -- a new project.  ("Carl E. McMillin" <carlymac@earthlink.net>)
List pgsql-hackers
"Carl E. McMillin" <carlymac@earthlink.net> wrote:
>> ...That's one of the reasons I wrote Pl/Java.
>
> More power too you! I'd really like to hear more about this project. Is
>
> http://gborg.postgresql.org/project/pljava/projdisplay.php
>
> your URL?
>
Yes, it is.

> I'm now in complete agreement: app-server doesn't fit.  Do you have any
> suggestions?  Would a postgreslet be out of bounds, do you think?
>
"PostgreSQL Advanced Storage Server" perhaps :-)

> I admit my almost complete ignorance of how sensitive the postgres backend
> is to all the hazards of process-control: is the postgres process REALLY
> just another UNIX process?  Can I "exec" on top of it?  Can I fork?
>
Yes (on a Unix platform), yes, and yes (again, on Unix. Windows doesn't have
fork).

> Can I have a child-process using IPC wait for 10 mins for its connected
process do
> its work without hosing the postmaster with its shared memory locks and
all
> that?  I've held off any serious development along these lines since I
don't
> have the time to do heavy code-trawling, that seeming the only way of
> obtaining the level of detail necessary to do the job well.
>
I think so although I haven't tried it so I'm not completely sure about
timeouts. I guess that if there indeed are such timeouts, they are
configurable.

The main concern is probably not the stuff that you address. The really hard
part is transaction coordination. What if the process you start have some
side effects? What if the call that was issued through PostgreSQL is rolled
back? PostgreSQL currently lacks a way to subscribe to transactional events
so there's no way your code can detect the outcome of a transaction.

> I would most definitely use embedded java if it could do at-minimum SRF's
> and spawn processes.  Something similar to SPI for Java would be pretty
> useful too, I imagine.
>
It's there already. Pl/Java comes with a JDBC driver implemented on top of
SPI. And using it, you are of course running in the same transaction as the
origin of the call to Java.

Kind regards,

Thomas Hallgren




pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: [COMMITTERS] pgsql-server: Clean up generation of
Next
From: Christopher Kings-Lynne
Date:
Subject: Coding question