[Pljava-dev] stack depth limit exceeded (NOT from infinite recursion)

Thanks a lot Thomas, "set the max_stack_depth to a ridiculously high
value" appeared to work around the problem for now. This is the
quickest solution at the moment and I will try that till I see another
problem.

Thanks again.

Regards,
Kong

Thomas Hallgren wrote:

> Kong,
> PostgreSQL only defines one stack, and thus one stack_depth_limit.
> It's not built for multiple threads and at present and PL/Java has no
> way of telling PostgreSQL that another thread is about to do
> something. PostgreSQL still thinks it's the same stack, hence the
> problem. The stack-depth of the other thread is irrelevant. The
> problem is caused by PostgreSQL comparing the stack_pointer from one
> stack with the stack_base from another.
>
> You encounter this problem because a thread other then the main thread
> is the first to encounter a class. That causes the classloader to make
> an attempt to load the class in that thread. If you can find out what
> class it is and then reference this class in advance from the main
> thread, the problem will go away since the main thread will be the one
> that loads the class.
>
> An alternative to this is to set the max_stack_depth to a ridiculously
> high value and thus turn of stack checks altogether. I don't think
> that will cause a major problem anyway. If you run into a
> stack-overflow, the process will page-fault and terminate.
>
> I know none of those solutions are ideal but until I can convince the
> PostgreSQL people to provide a function whereby I can set another
> stack_base, there's nothing else I can do.
>
> Regards,
> Thomas Hallgren
>
> kstian wrote:
>
>> Hi Thomas,
>>
>> Thanks a lot for the info. I went through reorganizing the installed
>> jar file and reduced the size of the jar file to contain about 263
>> required class files (as compared to thousands originally). Then I
>> re-ran the 3rd party connection from within pljava again and still
>> seeing the same 'stack depth limit exceeded' problem.
>>
>> May I know what is the stack depth limit for the second thread that
>> spawned from pljava? As of now, I have no idea how to work around
>> this problem.
>>
>> Thanks so much.
>>
>> Regards,
>> Kong
>>
>> Thomas Hallgren wrote:
>>
>>> OK, I see the problem. The connection spawns a new thread, that
>>> thread loads classes. And of course, the stack of that thread cannot
>>> be compared to the stack of the caller thread. PostgresSQL (since
>>> it's singlethreaded) thinks that you eat a vast amount of stack.
>>>
>>> I'll address this on the PostgreSQL hackers mailing list and see if
>>> I can convince them to install something that makes it possible to
>>> temporary shut off the stack-check. A temporary work-around is to
>>> reference the needed classes before making the connect call. That
>>> way, the current thread will be the one who loads them.
>>>
>>> Regards,
>>> Thomas Hallgren
>>
>>
>
>
>
>