From: | books at ejurka(dot)com (Kris Jurka) |
---|---|
To: | |
Subject: | [Pljava-dev] stack depth limit exceeded - patch possible? |
Date: | 2008-04-16 16:16:15 |
Message-ID: | 4806264F.1060800@ejurka.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pljava-dev |
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://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20080416/73b24a12/attachment.bin>
From | Date | Subject | |
---|---|---|---|
Next Message | Gaetano Mendola | 2008-04-16 16:17:20 | /etc/init.d/postgresql status error |
Previous Message | Gregory Stark | 2008-04-16 16:15:38 | Re: Improving planner variable handling |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Wöhrer | 2008-04-17 13:22:47 | [Pljava-dev] stack depth limit exceeded - patch possible? |
Previous Message | Alexander Wöhrer | 2008-04-16 14:36:22 | [Pljava-dev] stack depth limit exceeded - patch possible? |