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

Kris Jurka books at ejurka.com
Wed Apr 16 16:16:15 UTC 2008


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: portal-stack-adjust.patch
Type: text/x-patch
Size: 4358 bytes
Desc: not available
Url : http://pgfoundry.org/pipermail/pljava-dev/attachments/20080416/73b24a12/attachment.bin 


More information about the Pljava-dev mailing list