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

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
>