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

[Alexander Wöhrer]

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/
**********************************************