[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