agora inbox for pljava-dev@postgresql.org
help / color / mirror / Atom feedFrom: Dave Cramer <pg@fastcrypt.com>
To: Thomas Hallgren <thomas@tada.se>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Martijn van Oosterhout <kleptog@svana.org>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: PL/Java Development <Pljava-dev@gborg.postgresql.org>
Subject: Re: Shared memory
Date: Tue, 28 Mar 2006 13:27:02 -0500
Message-ID: <27F0779D-C696-4A39-9CA9-0228C6BABF56@fastcrypt.com> (raw)
In-Reply-To: <44296E24.5010602@tada.se>
References: <4423CF32.3060406@tada.se>
<20060324125851.GC8718@svana.org>
<4427A8F1.3020009@tada.se>
<14559.1143473507@sss.pgh.pa.us>
<4428125D.7000707@tada.se>
<1143541439.3839.323.camel@localhost.localdomain>
<44295AB0.5060203@tada.se>
<2966.1143563883@sss.pgh.pa.us>
<44296E24.5010602@tada.se>
On 28-Mar-06, at 12:11 PM, Thomas Hallgren wrote:
> Tom Lane wrote:
>> Thomas Hallgren <thomas@tada.se> writes:
>>
>>> This FENCED/NOT FENCED terminology would be a good way to
>>> differentiate between the two approaches. Any chance of that syntax
>>> making it into the PostgreSQL grammar, should the need arise?
>>>
>>
>> Of what value would it be to have it in the grammar? The behavior
>> would
>> be entirely internal to any particular PL in any case.
>>
>>
> Not necessarily but perhaps the term FENCED is incorrect for the
> concept that I have in mind.
>
> All languages that are implemented using a VM could benefit from
> the same remote UDF protocol. Java, C#, perhaps even Perl or Ruby.
> The flag that I'd like to have would control 'in-process' versus
> 'remote'.
>
> I'm not too keen on the term FENCED, since it, in the PL/Java case
> will lead to poorer isolation. Multiple threads running in the same
> JVM will be able to share data and a JVM crash will affect all
> connected sessions.
When was the last time you saw a JVM crash ? These are very rare now.
In any case if it does fail, it's a JVM bug and can happen to any
code running and take the server down if it is in process.
>
> Then again, perhaps it's a bad idea to have this in the function
> declaration in the first place. A custom GUC parameter might be a
> better choice. It will not be possible to have some functions use
> the in-process approach and others to execute remotely but I doubt
> that will matter that much.
>
> I'm still eager to hear what it is in the current PL/Java that you
> consider fundamental unresolvable problems.
>
> Regards,
> Thomas Hallgren
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that
> your
> message can get through to the mailing list cleanly
>
view thread (22+ messages) latest in thread
Message-ID: <27F0779D-C696-4A39-9CA9-0228C6BABF56@fastcrypt.com>
Permalink: ../27F0779D-C696-4A39-9CA9-0228C6BABF56@fastcrypt.com/
Also on: postgresql.org/message-id/27F0779D-C696-4A39-9CA9-0228C6BABF56@fastcrypt.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pljava-dev@postgresql.org
Cc: pg@fastcrypt.com, thomas@tada.se, tgl@sss.pgh.pa.us, simon@2ndquadrant.com, kleptog@svana.org, pgsql-hackers@postgresql.org, Pljava-dev@gborg.postgresql.org
Subject: Re: Shared memory
In-Reply-To: <27F0779D-C696-4A39-9CA9-0228C6BABF56@fastcrypt.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox