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>
Mime-Version: 1.0 (Apple Message framework v746.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <27F0779D-C696-4A39-9CA9-0228C6BABF56@fastcrypt.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>,
	Martijn van Oosterhout <kleptog@svana.org>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	PL/Java Development <Pljava-dev@gborg.postgresql.org>
Content-Transfer-Encoding: 7bit
From: Dave Cramer <pg@fastcrypt.com>
Subject: Re: Shared memory
Date: Tue, 28 Mar 2006 13:27:02 -0500
To: Thomas Hallgren <thomas@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
>