[Pljava-dev] doubtful PL/Java's activity

Hi,

I'm investigating PL/Java and find out a doubtful fact.

Postgres is compiled as a single thread application
and linked with JavaVM(.so/.dll) which is a multi thread library.
Sp, I think PL/Java's activity may not be assured.

Thread-unsafe functions and global variables used in single thread
standard libraries may be inconsistent with multi thread libraries.

Can anybody respond me ?

Regards.
-----
Y.Taniguchi

PL/Java goes to some length in protecting the single threaded PostgreSQL kernel. All accesses to it must be made from
the caller thread. Multiple threads can be used for background tasks but such threads will be completely blocked from
accessing the PostgreSQL functions.

It works like this:
A call is made from PostgreSQL. This call grabs a mutex.
During PL/Java execution, only the thread that owns the mutex can call PostgreSQL.
When the call eventually returns, the mutex is released.

Java maintenance (garbage collection for instance) will still run in separate threads. If someone should write a
finalizer that actually tries to do database access (god forbid), then that finalizer would throw an exception.

- thomas

On 2013-12-09 12:16, Taniguchi, Yasunori wrote:
> Hi,
>
> I'm investigating PL/Java and find out a doubtful fact.
>
> Postgres is compiled as a single thread application
> and linked with JavaVM(.so/.dll) which is a multi thread library.
> Sp, I think PL/Java's activity may not be assured.
>
> Thread-unsafe functions and global variables used in single thread
> standard libraries may be inconsistent with multi thread libraries.
>
> Can anybody respond me ?
>
>
> Regards.
> -----
> Y.Taniguchi
>
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

Hello

On Mon, 9 Dec 2013 11:16:01 +0000
"Taniguchi, Yasunori" <taniguchi.yasu at jp.fujitsu.com> wrote:

> Hi,
>
> I'm investigating PL/Java and find out a doubtful fact.
>
> Postgres is compiled as a single thread application
> and linked with JavaVM(.so/.dll) which is a multi thread library.
> Sp, I think PL/Java's activity may not be assured.
>
> Thread-unsafe functions and global variables used in single thread
> standard libraries may be inconsistent with multi thread libraries.

If I understood it correctly, every PostgreSQL connection has its own
process and for every such process one separate JVM is started.
This model ensures that different connections never end up in the
same JVM. Inside one connection queries are always executed one after
another. Therefore the JVM can internally do what ever it likes, even
multithreaded.

Best Regards

-christian-

I think you?re confusing things here. Yes, the PostgreSQL session is single threaded. But this is managed at the JDBC interface to the PostgreSQL session. So you simply do not have multiple threads doing unsafe things to the PostgreSQL session. It just doesn?t happen. You may, of course, have multiple Java threads in the JVM that resides in the PostgreSQL session. But any interaction with the session is serialized, so this isn?t a problem at all.

On Dec 9, 2013, at 3:16 AM, Taniguchi, Yasunori <taniguchi.yasu at jp.fujitsu.com> wrote:

> Hi,
>
> I'm investigating PL/Java and find out a doubtful fact.
>
> Postgres is compiled as a single thread application
> and linked with JavaVM(.so/.dll) which is a multi thread library.
> Sp, I think PL/Java's activity may not be assured.
>
> Thread-unsafe functions and global variables used in single thread
> standard libraries may be inconsistent with multi thread libraries.
>
> Can anybody respond me ?
>
>
> Regards.
> -----
> Y.Taniguchi
>
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

Hi,

Thank you, everyone.
Excuse me my poor explanation.
So, I made a figure.
Look attachment.
Red arrow in this fig. is unlikely ?

> You may, of course, have multiple Java threads in the JVM that resides in the PostgreSQL session. But any interaction with the session is serialized, so this isn?t a problem at all.

I worry about interaction between PostgreSQL and JVM library functions rather than interaction with the session.

> PL/Java goes to some length in protecting the single threaded PostgreSQL kernel. All accesses to it must be made from the caller thread. Multiple threads > can be used for background tasks but such threads will be completely blocked from accessing the PostgreSQL functions.
>
> It works like this:
> A call is made from PostgreSQL. This call grabs a mutex.
> During PL/Java execution, only the thread that owns the mutex can call PostgreSQL.
> When the call eventually returns, the mutex is released.

If I'm correct, PL/Java is also a single thread library ?
If so, it would not be a problem.

> Java maintenance (garbage collection for instance) will still run in separate threads. If someone should write a finalizer that actually tries to do database access (god forbid), then that finalizer would throw an exception.

Uh.. It may become a restriction of usage.
Probably, some restrictions else would exist, doesn't it?

Regards.

-----Original Message-----
From: pljava-dev-bounces at lists.pgfoundry.org [mailto:pljava-dev-bounces at lists.pgfoundry.org] On Behalf Of Thomas Hallgren
Sent: Thursday, December 12, 2013 5:16 PM
To: pljava-dev at lists.pgfoundry.org
Subject: Re: [Pljava-dev] doubtful PL/Java's activity

PL/Java goes to some length in protecting the single threaded PostgreSQL kernel. All accesses to it must be made from the caller thread. Multiple threads can be used for background tasks but such threads will be completely blocked from accessing the PostgreSQL functions.

It works like this:
A call is made from PostgreSQL. This call grabs a mutex.
During PL/Java execution, only the thread that owns the mutex can call PostgreSQL.
When the call eventually returns, the mutex is released.

Java maintenance (garbage collection for instance) will still run in separate threads. If someone should write a finalizer that actually tries to do database access (god forbid), then that finalizer would throw an exception.

- thomas

On 2013-12-09 12:16, Taniguchi, Yasunori wrote:
> Hi,
>
> I'm investigating PL/Java and find out a doubtful fact.
>
> Postgres is compiled as a single thread application and linked with
> JavaVM(.so/.dll) which is a multi thread library.
> Sp, I think PL/Java's activity may not be assured.
>
> Thread-unsafe functions and global variables used in single thread
> standard libraries may be inconsistent with multi thread libraries.
>
> Can anybody respond me ?
>
>
> Regards.
> -----
> Y.Taniguchi
>
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

_______________________________________________
Pljava-dev mailing list
Pljava-dev at lists.pgfoundry.org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thread model evaluation.xls
Type: application/vnd.ms-excel
Size: 99840 bytes
Desc: thread model evaluation.xls
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20131213/80e39126/attachment-0001.xls>

If I understand you correctly, you?re talking about the recursive invocation case:

SQL -> PL/Java -> SQL - PL/Java

Yes, you are correct. If you have multiple threads running in your JVM, then you can get into serious trouble if you don?t know what you?re doing.

However:

why do you have multiple threads?
if you have multiple threads, then why aren?t you designing your systems to accommodate this?

Bottom line is that this should be completely under your control. In any event, it?s caveat emptor. With great power comes great responsibility. If you don?t want multithreaded problems, then don?t spawn multiple threads. You can install a security manager that prevents this, you know ;)

And if you have multiple threads in your stored procedure calls, then you?re going to have to deal with that. Not the responsibility of the PL/Java implementation to take care of the messes you, yourself, create.

On Dec 12, 2013, at 5:57 PM, Taniguchi, Yasunori <taniguchi.yasu at jp.fujitsu.com> wrote:

> Hi,
>
> Thank you, everyone.
> Excuse me my poor explanation.
> So, I made a figure.
> Look attachment.
> Red arrow in this fig. is unlikely ?
>
>
>> You may, of course, have multiple Java threads in the JVM that resides in the PostgreSQL session. But any interaction with the session is serialized, so this isn?t a problem at all.
>
> I worry about interaction between PostgreSQL and JVM library functions rather than interaction with the session.
>
>
>> PL/Java goes to some length in protecting the single threaded PostgreSQL kernel. All accesses to it must be made from the caller thread. Multiple threads > can be used for background tasks but such threads will be completely blocked from accessing the PostgreSQL functions.
>>
>> It works like this:
>> A call is made from PostgreSQL. This call grabs a mutex.
>> During PL/Java execution, only the thread that owns the mutex can call PostgreSQL.
>> When the call eventually returns, the mutex is released.
>
> If I'm correct, PL/Java is also a single thread library ?
> If so, it would not be a problem.
>
>
>> Java maintenance (garbage collection for instance) will still run in separate threads. If someone should write a finalizer that actually tries to do database access (god forbid), then that finalizer would throw an exception.
>
> Uh.. It may become a restriction of usage.
> Probably, some restrictions else would exist, doesn't it?
>
>
> Regards.
>
> -----Original Message-----
> From: pljava-dev-bounces at lists.pgfoundry.org [mailto:pljava-dev-bounces at lists.pgfoundry.org] On Behalf Of Thomas Hallgren
> Sent: Thursday, December 12, 2013 5:16 PM
> To: pljava-dev at lists.pgfoundry.org
> Subject: Re: [Pljava-dev] doubtful PL/Java's activity
>
> PL/Java goes to some length in protecting the single threaded PostgreSQL kernel. All accesses to it must be made from the caller thread. Multiple threads can be used for background tasks but such threads will be completely blocked from accessing the PostgreSQL functions.
>
> It works like this:
> A call is made from PostgreSQL. This call grabs a mutex.
> During PL/Java execution, only the thread that owns the mutex can call PostgreSQL.
> When the call eventually returns, the mutex is released.
>
> Java maintenance (garbage collection for instance) will still run in separate threads. If someone should write a finalizer that actually tries to do database access (god forbid), then that finalizer would throw an exception.
>
> - thomas
>
> On 2013-12-09 12:16, Taniguchi, Yasunori wrote:
>> Hi,
>>
>> I'm investigating PL/Java and find out a doubtful fact.
>>
>> Postgres is compiled as a single thread application and linked with
>> JavaVM(.so/.dll) which is a multi thread library.
>> Sp, I think PL/Java's activity may not be assured.
>>
>> Thread-unsafe functions and global variables used in single thread
>> standard libraries may be inconsistent with multi thread libraries.
>>
>> Can anybody respond me ?
>>
>>
>> Regards.
>> -----
>> Y.Taniguchi
>>
>>
>> _______________________________________________
>> Pljava-dev mailing list
>> Pljava-dev at lists.pgfoundry.org
>> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
> <thread model evaluation.xls>_______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20131212/f8d79418/attachment.html>

Thanx Thomas,
for the insight.

On 12/12/2013 10:15, Thomas Hallgren wrote:
> PL/Java goes to some length in protecting the single threaded PostgreSQL kernel. All accesses to it must be made from the caller thread. Multiple threads can be used for background tasks but such
> threads will be completely blocked from accessing the PostgreSQL functions.
>
> It works like this:
> A call is made from PostgreSQL. This call grabs a mutex.
> During PL/Java execution, only the thread that owns the mutex can call PostgreSQL.
> When the call eventually returns, the mutex is released.
>
> Java maintenance (garbage collection for instance) will still run in separate threads. If someone should write a finalizer that actually tries to do database access (god forbid), then that finalizer
> would throw an exception.
>
> - thomas
>
> On 2013-12-09 12:16, Taniguchi, Yasunori wrote:
>> Hi,
>>
>> I'm investigating PL/Java and find out a doubtful fact.
>>
>> Postgres is compiled as a single thread application
>> and linked with JavaVM(.so/.dll) which is a multi thread library.
>> Sp, I think PL/Java's activity may not be assured.
>>
>> Thread-unsafe functions and global variables used in single thread
>> standard libraries may be inconsistent with multi thread libraries.
>>
>> Can anybody respond me ?
>>
>>
>> Regards.
>> -----
>> Y.Taniguchi
>>
>>
>> _______________________________________________
>> Pljava-dev mailing list
>> Pljava-dev at lists.pgfoundry.org
>> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

--
Achilleas Mantzios

Thank you, Mr. Thomas,

Sorry for my late response.

> The backend is single threaded (each connection runs in it's own process and it's own JVM) so there will never be two functions executing simultanously.

Yes, I understand.
But, multi thread applications (unless using concurrent JDBC call) can run in JavaVM even if postgres backend is single threaded, I think.

After received this mail, I discussed with colleague and recognized :

- PL/Java runs without any problems even if PL/Java's and JavaVM's are compiled as multi thread library.
Single thread compiled application uses standard library which contains thread-unsafe functions.
These thread-unsafe functions uses common global variable between them. Therefore they are thread-unsafe.
On the other hand, multi thread complied application uses standard library consists of thread-safe functions.
Thread-safe functions uses separated global variables.
As above, there is no problem unless any global variable (eg. errno) is passed across between single thread compiled application and multi thread one.

- PL/Java runs without any problems even if multi thread Java applications not using concurrent JDBC call runs.

In addition,
Java multi thread application can run thread-unsafe function in single thread library through JNI.
But, this case is abuse.

Any comments are appreciated.

Regards, taniguchi

-----Original Message-----
From: Thomas Hallgren [mailto:ironjug at gmail.com] On Behalf Of Thomas Hallgren
Sent: Friday, December 13, 2013 3:21 PM
To: Taniguchi, Yasunori
Subject: Re: [Pljava-dev] doubtful PL/Java's activity

On 2013-12-13 02:57, Taniguchi, Yasunori wrote:
> Hi,
>
> Thank you, everyone.
> Excuse me my poor explanation.
> So, I made a figure.
> Look attachment.
> Red arrow in this fig. is unlikely ?
The backend is single threaded (each connection runs in it's own process and it's own JVM) so there will never be two functions executing simultanously.

>
>> You may, of course, have multiple Java threads in the JVM that resides in the PostgreSQL session. But any interaction with the session is serialized, so this isn?t a problem at all.
> I worry about interaction between PostgreSQL and JVM library functions rather than interaction with the session.
Again, PostgreSQL is single threaded. It cannot interact in more than
one thread.

>
>> PL/Java goes to some length in protecting the single threaded PostgreSQL kernel. All accesses to it must be made from the caller thread. Multiple threads > can be used for background tasks but such threads will be completely blocked from accessing the PostgreSQL functions.
>>
>> It works like this:
>> A call is made from PostgreSQL. This call grabs a mutex.
>> During PL/Java execution, only the thread that owns the mutex can call PostgreSQL.
>> When the call eventually returns, the mutex is released.
> If I'm correct, PL/Java is also a single thread library ?
> If so, it would not be a problem.
No, PL/Java is not a single thread library. There is however, never more
than one thread that calls on it and never more than one thread that can
call out from it.

>
>> Java maintenance (garbage collection for instance) will still run in separate threads. If someone should write a finalizer that actually tries to do database access (god forbid), then that finalizer would throw an exception.
> Uh.. It may become a restriction of usage.
> Probably, some restrictions else would exist, doesn't it?

Yes, it is a very deliberate restriction of usage. Don't start new
threads that uses the JDBC driver. Don't use the JDBC driver from a
finalizer. Both those cases would violate the single threaded nature of
the backend.

- thomas

On 2013-12-20 05:51, Taniguchi, Yasunori wrote:
> Thank you, Mr. Thomas,
>
> Sorry for my late response.
>
>> The backend is single threaded (each connection runs in it's own process and it's own JVM) so there will never be two functions executing simultanously.
> Yes, I understand.
> But, multi thread applications (unless using concurrent JDBC call) can run in JavaVM even if postgres backend is single threaded, I think.

Each connection that a multi threaded client application opens is attached to one single threaded backend process and
hence, each connection will run in its own JVM. These connections cannot access the same global data since they live in
different process spaces.

- thomas

Hi, Mr. Thomas,

"application" I described means general application like postgres, PL/Java library, JavaVM and so on.
It's not database client application.

postgres(single thread compiled) <=> PL/Java lib(multi thread compiled) <=> JavaVM lib(multi thread compiled)

My recognition is :

- no global variable is passed across between postgres and PL/Java lib, JavaVM lib
(only function arguments and return value are passed across.)

- PL/Java lib, JavaVM lib functions never call functions in postgres lib.

Regards, Taniguchi

-----Original Message-----
From: pljava-dev-bounces at lists.pgfoundry.org [mailto:pljava-dev-bounces at lists.pgfoundry.org] On Behalf Of Thomas Hallgren
Sent: Friday, December 20, 2013 3:14 PM
To: pljava-dev at lists.pgfoundry.org
Subject: Re: [Pljava-dev] doubtful PL/Java's activity

On 2013-12-20 05:51, Taniguchi, Yasunori wrote:
> Thank you, Mr. Thomas,
>
> Sorry for my late response.
>
>> The backend is single threaded (each connection runs in it's own process and it's own JVM) so there will never be two functions executing simultanously.
> Yes, I understand.
> But, multi thread applications (unless using concurrent JDBC call) can run in JavaVM even if postgres backend is single threaded, I think.

Each connection that a multi threaded client application opens is attached to one single threaded backend process and hence, each connection will run in its own JVM. These connections cannot access the same global data since they live in different process spaces.

- thomas

_______________________________________________
Pljava-dev mailing list
Pljava-dev at lists.pgfoundry.org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

I'm sorry Taniguchi, but then I don't understand what you're concerned about. You write:

> Java multi thread application can run thread-unsafe function in single thread library through JNI.
> But, this case is abuse.

and I've explained to you that it is _impossible_ that multiple threads do this simultaneously. It's all well protected
using mutex. So where is the abuse?

- thomas

On 2013-12-20 07:34, Taniguchi, Yasunori wrote:
> Hi, Mr. Thomas,
>
> "application" I described means general application like postgres, PL/Java library, JavaVM and so on.
> It's not database client application.
>
> postgres(single thread compiled) <=> PL/Java lib(multi thread compiled) <=> JavaVM lib(multi thread compiled)
>
>
> My recognition is :
>
> - no global variable is passed across between postgres and PL/Java lib, JavaVM lib
> (only function arguments and return value are passed across.)
>
> - PL/Java lib, JavaVM lib functions never call functions in postgres lib.
>
>
>
> Regards, Taniguchi
>
>
> -----Original Message-----
> From: pljava-dev-bounces at lists.pgfoundry.org [mailto:pljava-dev-bounces at lists.pgfoundry.org] On Behalf Of Thomas Hallgren
> Sent: Friday, December 20, 2013 3:14 PM
> To: pljava-dev at lists.pgfoundry.org
> Subject: Re: [Pljava-dev] doubtful PL/Java's activity
>
> On 2013-12-20 05:51, Taniguchi, Yasunori wrote:
>> Thank you, Mr. Thomas,
>>
>> Sorry for my late response.
>>
>>> The backend is single threaded (each connection runs in it's own process and it's own JVM) so there will never be two functions executing simultanously.
>> Yes, I understand.
>> But, multi thread applications (unless using concurrent JDBC call) can run in JavaVM even if postgres backend is single threaded, I think.
> Each connection that a multi threaded client application opens is attached to one single threaded backend process and hence, each connection will run in its own JVM. These connections cannot access the same global data since they live in different process spaces.
>
> - thomas
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

> Taniguchi

> On Dec 20, 2013, at 2:02 AM, Thomas Hallgren <thomas at tada.se> wrote:
>
> I'm sorry Taniguchi, but then I don't understand what you're concerned about. You write:
>
> > Java multi thread application can run thread-unsafe function in single thread library through JNI.
> > But, this case is abuse.
>
> and I've explained to you that it is _impossible_ that multiple threads do this simultaneously. It's all well protected using mutex. So where is the abuse?
>
> - thomas
>
>
>> On 2013-12-20 07:34, Taniguchi, Yasunori wrote:
>> Hi, Mr. Thomas,
>>
>> "application" I described means general application like postgres, PL/Java library, JavaVM and so on.
>> It's not database client application.
>>
>> postgres(single thread compiled) <=> PL/Java lib(multi thread compiled) <=> JavaVM lib(multi thread compiled)
>>
>>
>> My recognition is :
>>
>> - no global variable is passed across between postgres and PL/Java lib, JavaVM lib
>> (only function arguments and return value are passed across.)
>>
>> - PL/Java lib, JavaVM lib functions never call functions in postgres lib.
>>
>>
>>
>> Regards, Taniguchi
>>
>>
>> -----Original Message-----
>> From: pljava-dev-bounces at lists.pgfoundry.org [mailto:pljava-dev-bounces at lists.pgfoundry.org] On Behalf Of Thomas Hallgren
>> Sent: Friday, December 20, 2013 3:14 PM
>> To: pljava-dev at lists.pgfoundry.org
>> Subject: Re: [Pljava-dev] doubtful PL/Java's activity
>>
>>> On 2013-12-20 05:51, Taniguchi, Yasunori wrote:
>>> Thank you, Mr. Thomas,
>>>
>>> Sorry for my late response.
>>>
>>>> The backend is single threaded (each connection runs in it's own process and it's own JVM) so there will never be two functions executing simultanously.
>>> Yes, I understand.
>>> But, multi thread applications (unless using concurrent JDBC call) can run in JavaVM even if postgres backend is single threaded, I think.
>> Each connection that a multi threaded client application opens is attached to one single threaded backend process and hence, each connection will run in its own JVM. These connections cannot access the same global data since they live in different process spaces.
>>
>> - thomas
>>
>> _______________________________________________
>> Pljava-dev mailing list
>> Pljava-dev at lists.pgfoundry.org
>> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
>> _______________________________________________
>> Pljava-dev mailing list
>> Pljava-dev at lists.pgfoundry.org
>> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev
>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

Taniguchi, perhaps it would be far better for you to provide a test case with code demonstrating your concern.

This will either convince you that the problem does not exist, or provide us with code that demonstrates the problem.

> On Dec 20, 2013, at 2:02 AM, Thomas Hallgren <thomas at tada.se> wrote:
> Taniguchi

Thanks, Hal and Thomas

> Taniguchi, perhaps it would be far better for you to provide a test case with code demonstrating your concern.
> This will either convince you that the problem does not exist, or provide us with code that demonstrates the problem.

I'll do this.
After that, I'll post the results to here.

Regards, Taniguchi

-----Original Message-----
From: pljava-dev-bounces at lists.pgfoundry.org [mailto:pljava-dev-bounces at lists.pgfoundry.org] On Behalf Of Hal Hildebrand
Sent: Friday, December 20, 2013 9:56 PM
To: Thomas Hallgren
Cc: pljava-dev at lists.pgfoundry.org
Subject: Re: [Pljava-dev] doubtful PL/Java's activity

Taniguchi, perhaps it would be far better for you to provide a test case with code demonstrating your concern.

This will either convince you that the problem does not exist, or provide us with code that demonstrates the problem.

> On Dec 20, 2013, at 2:02 AM, Thomas Hallgren <thomas at tada.se> wrote:
> Taniguchi
_______________________________________________
Pljava-dev mailing list
Pljava-dev at lists.pgfoundry.org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev

Very cool. I look forward to it ;)

On Dec 20, 2013, at 4:55 AM, Hal Hildebrand <hal.hildebrand at me.com> wrote:

> Taniguchi, perhaps it would be far better for you to provide a test case with code demonstrating your concern.
>
> This will either convince you that the problem does not exist, or provide us with code that demonstrates the problem.
>
>> On Dec 20, 2013, at 2:02 AM, Thomas Hallgren <thomas at tada.se> wrote:
>> Taniguchi
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev