From: books at ejurka.com (Kris Jurka) Date: Wed, 16 Apr 2008 10:16:15 -0600 Subject: [Pljava-dev] stack depth limit exceeded - patch possible? In-Reply-To: <48060EE6.9040009@par.univie.ac.at> References: <48010499.30000@par.univie.ac.at> <58782.88.116.137.78.1208177811.squirrel@www.par.univie.ac.at> <48060EE6.9040009@par.univie.ac.at> Message-ID: <4806264F.1060800@ejurka.com> 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: