[Pljava-dev] stack depth limit exceeded - patch possible?
Alexander Wöhrer
woehrer at par.univie.ac.at
Wed Apr 16 14:36:22 UTC 2008
Dear Kris,
please find attached the log4j file for the application I want to
migrate into postgresql 8.3 as well as the corresponding postgresql log
file:
As you see, 3 threads are running without problems - but when one thread
executes a query like this
Connection conn = DriverManager.getConnection("jdbc:default:connection");
rs = conn.createStatement().executeQuery(query);
and later on tries to retrieve the results via rs.next() the
stack_depth_limit error appears (around 1000 rows should be returned by
the year - tried it in pgAdmin).
2008-04-16 14:17:36,359 INFO
service.QueryEvaluationServiceBindingImplInternal [main,evaluate:42]
************************************************************
2008-04-16 14:17:36,359 INFO
service.QueryEvaluationServiceBindingImplInternal [main,evaluate:43] *
Query execution starting, logging current memory usage *
2008-04-16 14:17:36,375 INFO
service.QueryEvaluationServiceBindingImplInternal [main,evaluate:44]
************************************************************
2008-04-16 14:17:36,375 INFO
service.QueryEvaluationServiceBindingImplInternal
[main,logMemoryUsage:131] [852832] of [532742144] bytes in use.
[0.16008344930188215]%
2008-04-16 14:17:36,468 INFO
service.QueryEvaluationServiceBindingImplInternal [main,evaluate:52]
Query ID: session-ogsadai-119571aa3a1
2008-04-16 14:17:36,484 INFO service.QueryExecutionEngine
[main,<init>:26] Creating the engine
2008-04-16 14:17:36,484 INFO service.QueryExecutionEngine
[main,<init>:30] Creating the th
2008-04-16 14:17:36,484 INFO service.TransportHandler [main,<init>:56]
Entering TransportHandler::TransportHandler
2008-04-16 14:17:36,484 INFO service.TransportHandler [main,<init>:58]
Exiting TransportHandler::TransportHandler
2008-04-16 14:17:36,484 INFO service.QueryExecutionEngine
[main,<init>:32] Creating the dt
2008-04-16 14:17:36,484 INFO service.DataTranslator [main,<init>:54]
Entering DataTranslator::DataTranslator for
context:session-ogsadai-119571aa3a1
2008-04-16 14:17:36,484 INFO service.DataTranslator [main,<init>:57]
Exiting DataTranslator::DataTranslator for
context:session-ogsadai-119571aa3a1
2008-04-16 14:17:36,484 INFO service.QueryExecutionEngine
[main,<init>:37] dtThrad started
2008-04-16 14:17:36,484 INFO service.DataTranslator
[session-ogsadai-119571aa3a1-translator,run:201] Reading buffer from the
queue
2008-04-16 14:17:36,593 DEBUG operators.ExchangeOp
[session-ogsadai-119571aa3a1-exchange-2,Open:367] 2: opening input operator
2008-04-16 14:17:36,593 INFO service.DataTranslator
[session-ogsadai-119571aa3a1-translator,TranslateXMLPacketToTuple:186]
Exiting DataTranslator::TranslateXMLToTuple for
context:session-ogsadai-119571aa3a1
2008-04-16 14:17:36,593 DEBUG operators.TableScanOp
[session-ogsadai-119571aa3a1-exchange-2,Open:213] Entering
TableScanOp:1:Open
2008-04-16 14:17:36,593 INFO service.DataTranslator
[session-ogsadai-119571aa3a1-translator,run:201] Reading buffer from the
queue
2008-04-16 14:17:36,593 DEBUG operators.TableScanOp
[session-ogsadai-119571aa3a1-exchange-2,Open:214] 1: Creating RowHandler...
2008-04-16 14:17:36,593 DEBUG utils.Queue
[session-ogsadai-119571aa3a1-translator,get:85] Entering Queue::get
2008-04-16 14:17:36,593 DEBUG operators.TableScanOp
[session-ogsadai-119571aa3a1-exchange-2,convertExpressionToQuery:339]
Entering TableScanOp::convertExpressionToQuery
2008-04-16 14:17:36,593 DEBUG utils.Queue
[session-ogsadai-119571aa3a1-translator,get:92] Waiting to read
2008-04-16 14:17:36,593 DEBUG operators.TableScanOp
[session-ogsadai-119571aa3a1-exchange-2,convertExpressionToQuery:362]
Exiting TableScanOp::convertExpressionToQuery
2008-04-16 14:17:36,593 DEBUG operators.TableScanOp
[session-ogsadai-119571aa3a1-exchange-2,ReplacePrefixedNamesWithOriginals:374]
Entering TableScanOp::ReplacePrefixedNamesWithOriginals
2008-04-16 14:17:36,593 INFO operators.TableScanOp
[session-ogsadai-119571aa3a1-exchange-2,Open:220] 1: Query string:
select id,pay1,pay2 from gotermext where (gotermext.type = 'cellular
component')
2008-04-16 14:17:36,593 DEBUG operators.TableScanOp
[session-ogsadai-119571aa3a1-exchange-2,Open:251] Exiting TableScanOp:1:Open
2008-04-16 14:17:36,593 DEBUG operators.ExchangeOp
[session-ogsadai-119571aa3a1-exchange-2,Open:380] 2: waiting for open()
to be completed
2008-04-16 14:17:36,593 DEBUG operators.ExchangeOp
[session-ogsadai-119571aa3a1-exchange-2,waitForOpen:214] (2) entering
waitForOpen()
2008-04-16 14:17:36,593 DEBUG operators.ExchangeOp
[session-ogsadai-119571aa3a1-exchange-2,waitForOpen:220] (2) received 2
opens out of 2
2008-04-16 14:17:36,593 DEBUG operators.ExchangeOp
[session-ogsadai-119571aa3a1-exchange-2,waitForOpen:224] (2) All opens
received, waking up waiting thread
2008-04-16 14:17:36,593 DEBUG operators.ExchangeOp
[session-ogsadai-119571aa3a1-exchange-2,enableExchange:258] Entering
ExchangeOp:2:enableExchange
2008-04-16 14:17:36,593 INFO operators.ExchangeOp
[session-ogsadai-119571aa3a1-exchange-2,enableExchange:276] Starting
next operation on root exchange 2
2008-04-16 14:17:36,593 DEBUG operators.ExchangeOp
[session-ogsadai-119571aa3a1-exchange-2,Next:406] Entering root
ExchangeOp:2:MainThread::Next
2008-04-16 14:17:36,593 DEBUG operators.TableScanOp
[session-ogsadai-119571aa3a1-exchange-2,Next:262] Entering
TableScanOp:1:Next
2008-04-16 14:17:36,593 INFO operators.TableScanOp
[session-ogsadai-119571aa3a1-exchange-2,Next:282] rs.next()
2008-04-16 14:17:36,593 ERROR operators.TableScanOp
[session-ogsadai-119571aa3a1-exchange-2,Next:306] 1: Error in getting
internal result row: stack depth limit exceeded
2304DEBUG: Added JVM option string "-Xmx512m"
2304DEBUG: Added JVM option string
"-Djava.class.path=D:/postgresql8.3/share/pljava/pljava.jar"
2304DEBUG: Added JVM option string
"-Dsqlj.defaultconnection=jdbc:default:connection"
2304DEBUG: Added JVM option string "vfprintf"
2304DEBUG: Added JVM option string "-Xrs"
2304DEBUG: Creating JavaVM
2304DEBUG: JavaVM created
2304DEBUG: Getting Backend class pljava.jar
2304DEBUG: Backend class was there
2304DEBUG: 16 Apr 08 14:17:36 org.postgresql.pljava.internal.Backend
Using SecurityManager for untrusted language
2304DEBUG: 16 Apr 08 14:17:36 org.postgresql.pljava.sqlj.Loader
Creating typeMappings for schema public
2304DEBUG: Loading class
uk.org.ogsadai.dqp.gqes.service.QueryEvaluationServiceBindingImplWrapper
2304DEBUG: Obtaining method
uk.org.ogsadai.dqp.gqes.service.QueryEvaluationServiceBindingImplWrapper.evaluate
([B)Ljava/lang/String;
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)
at
org.postgresql.pljava.jdbc.SPIResultSet.getTupleTable(SPIResultSet.java:137)
at
org.postgresql.pljava.jdbc.SPIResultSet.peekNext(SPIResultSet.java:164)
at org.postgresql.pljava.jdbc.SPIResultSet.next(SPIResultSet.java:80)
at
uk.org.ogsadai.dqp.gqes.operators.TableScanOp.Next(TableScanOp.java:284)
at
uk.org.ogsadai.dqp.gqes.operators.ExchangeOp.Next(ExchangeOp.java:416)
at
uk.org.ogsadai.dqp.gqes.operators.ExchangeOp.enableExchange(ExchangeOp.java:277)
at
uk.org.ogsadai.dqp.gqes.operators.ExchangeOp.waitForOpen(ExchangeOp.java:229)
at
uk.org.ogsadai.dqp.gqes.operators.ExchangeOp.Open(ExchangeOp.java:381)
at uk.org.ogsadai.dqp.gqes.operators.ExchangeOp.run(ExchangeOp.java:574)
at java.lang.Thread.run(Thread.java:595)
Any ideas why this happens? The application runs without any problems
outside postgresql 8.3.
Regards,
Alexander
Kris Jurka schrieb:
>
>
> On Mon, 14 Apr 2008, Alexander Wöhrer wrote:
>
>> am I understanding this correctly that pl/java sets it for the main Java
>> thread, so other threads spawned by this main thread and using postgres
>> SPI functionality will run into stack_depth_problems?
>
> pljava sets the stack_base_ptr for each thread just before it calls
> into the backend using SPI and resets it when that thread finishes
> using SPI. Only one thread can access the backend at a time, so
> multi-threaded pljava code is safe and this mangling of the
> stack_base_ptr keeps the backend happy.
>
>> Can you suggest another workaround?
>>
>
> Are you having any actual problems or is this all theoretical? I
> don't believe you should be having any issues, but if you're having a
> real problem, please post a self-contained test case so we can look
> into it.
>
> 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/
**********************************************
More information about the Pljava-dev
mailing list