[Pljava-dev] stack depth limit exceeded - patch possible?

Dear Kris,

first of all thank you very much for your fast response including a
patch suggestion for my issue.
I made the changes to the 2 pljava source files (one c File, one java
File changed) as proposed by you, assuming that

*** 153,159 ****
{
synchronized(Backend.THREADLOCK)
{
! return _move(m_pointer, forward, count);
}
}

--- 153,159 ----
{
synchronized(Backend.THREADLOCK)
{
! return _fetch(m_pointer, System.identityHashCode(Thread.currentThread()), forward, count);
}
}

***************

should be changed to the new return _move(.....) as well as done for the return _fetch(...).

As I never built postgresql nor pljava local on my Win XP maschine I installed mingw and msys, set msys\bin in my path and tried to build the pl/java release with

make release

from the root directory of the pljava src distribution (/e/downloads/pljava).

Then I get the following error:
make[1]: Entering directory `/e/downloads/pljava-1.4.0/build/classes/pljava'
javac -source 1.4 -target 1.4 -d . <java sources>
javac: no source files
make[1]: *** [.timestamp] Error 2
make[1]: Leaving directory `/e/downloads/pljava-1.4.0/build/classes/pljava'
make: *** [pljava_all] Error 2

What else do I have to set in order to get the built process working?

Regards,

Alexander

Kris Jurka schrieb:
> Alexander W?hrer wrote:
>> 2304DEBUG: Changed stack_base_ptr from 00BDFC9A to 0B1EFAF4
>> 2304DEBUG: Restored stack_base_ptr to 00BDFC9A
>> 2304DEBUG: Changed stack_base_ptr from 00BDFC9A to 0B1EFAC8
>> 2304DEBUG: Restored stack_base_ptr to 00BDFC9A
>> 2304DEBUG: Exception in function SPI_cursor_fetch
>> org.postgresql.pljava.internal.ServerException: stack depth limit
>> exceeded
>> at org.postgresql.pljava.internal.Portal._fetch(Native Method)
>> at org.postgresql.pljava.internal.Portal.fetch(Portal.java:91)
>
> So you can see the initial stack_base_ptr being adjusted when the
> query is initially executed. Unfortunately pljava is not adjusting it
> again later when rs.next() is being called. So if the portal fetch
> needs to do any actual work (that is the results were not materialized
> by the initial execution) it needs to adjust the stack as well. Can
> you try the attached patch to see if it fixes things for you?
>
> In general it seems that anything operating inside of
> synchronized(Backend.THREADLOCK) might need to adjust the stack unless
> it's certain the work it's doing is trivial and won't invoke
> check_stack_depth. Unfortunately I don't know enough about when pg
> calls check_stack_depth to know offhand what is/is not safe. A more
> thorough audit is required here. Let's start with this patch and see
> where that gets us.
>
> Kris Jurka
>

--
**********************************************
University of Vienna
Institute for Scientific Computing
Nordbergstra?e 15/C/311
A-1090 Vienna
Austria

tel.: +43-1-4277-39421
fax.: +43-1-4277-9394
e-mail: woehrer at par.univie.ac.at
url: http://www.par.univie.ac.at/~woehrer/
**********************************************