agora inbox for pljava-dev@postgresql.org
help / color / mirror / Atom feed[Pljava-dev] stack depth limit exceeded - patch possible?
11+ messages / 2 participants
[nested] [flat]
* [Pljava-dev] stack depth limit exceeded - patch possible?
@ 2008-04-12 18:51
0 siblings, 1 reply; 11+ messages in thread
From: @ 2008-04-12 18:51 UTC (permalink / raw)
Dear PL/Java Team,
I'm working on Windows XP SP2 (stack limit 3500 kb) and deployed
successfully my application (doing some external Web service calling)
inside PostGre 8.3.0.
Unfortunatelly, the application needs at least 3 Threads and will run
for quite some time.
I found this comment
http://pgfoundry.org/pipermail/pljava-dev/2005/000491.html
by Thomas Hallgren where he mentioned that PostGre only defines
one stack and therefor pl/java has no way of telling PostGre
about multiple thread stack pointers.
As far as I understand the situation, the check_stack_depth()
is used "just" to provide better stability/security?
I'm not concerned about stability at all - just want to get
my things run for a proof-of-concept research prototype :)
My question is now if there is a patched version available of PostGre
8.3.0 having this stack_depth check disabled?
If so I would be very glad if you can point me to!
If not, can you tell me if
void check_stack_depth(void) in \src\backend\tcop\postgres.c
is the only place where to change something
(in my case just do nothing or report a warning)?
My C developer times are long gone but I would try to make a patch
myself.
Regards,
Alexander
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [Pljava-dev] stack depth limit exceeded - patch possible?
@ 2008-04-13 14:25 Kris Jurka <books@ejurka.com>
parent:
0 siblings, 1 reply; 11+ messages in thread
From: Kris Jurka @ 2008-04-13 14:25 UTC (permalink / raw)
To: Alexander Wöhrer <woehrer@par.univie.ac.at>; +Cc: pljava-dev@pgfoundry.org; pgsql-hackers@postgresql.org
On Sat, 12 Apr 2008, Alexander Wöhrer wrote:
> I'm working on Windows XP SP2 (stack limit 3500 kb) and deployed
> successfully my application (doing some external Web service calling)
> inside PostGre 8.3.0.
>
> Unfortunatelly, the application needs at least 3 Threads and will run
> for quite some time.
>
> I found this comment
>
> http://pgfoundry.org/pipermail/pljava-dev/2005/000491.html
>
> by Thomas Hallgren where he mentioned that PostGre only defines
> one stack and therefor pl/java has no way of telling PostGre
> about multiple thread stack pointers.
>
> My question is now if there is a patched version available of PostGre
> 8.3.0 having this stack_depth check disabled?
This was fixed in postgresql/pljava shortly after the referenced
discussion. As requested, postgresql 8.1+ allows modification of
stack_base_ptr so pljava can set it as desired.
Kris Jurka
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [Pljava-dev] stack depth limit exceeded - patch possible?
@ 2008-04-14 12:56 Alexander Wöhrer <woehrer@par.univie.ac.at>
parent: Kris Jurka <books@ejurka.com>
0 siblings, 1 reply; 11+ messages in thread
From: Alexander Wöhrer @ 2008-04-14 12:56 UTC (permalink / raw)
To: Kris Jurka <books@ejurka.com>; +Cc: pljava-dev@pgfoundry.org; pgsql-hackers@postgresql.org
Dear Kris,
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?
I have read only access in this application, so maybe my envisioned
patched version (check_stack_depth doing nothing) will work for my proof
of concept tests.
Can you suggest another workaround?
Regards,
Alexander Wöhrer
>
>
> On Sat, 12 Apr 2008, Alexander Wöhrer wrote:
>
>> I'm working on Windows XP SP2 (stack limit 3500 kb) and deployed
>> successfully my application (doing some external Web service calling)
>> inside PostGre 8.3.0.
>>
>> Unfortunatelly, the application needs at least 3 Threads and will run
>> for quite some time.
>>
>> I found this comment
>>
>> http://pgfoundry.org/pipermail/pljava-dev/2005/000491.html
>>
>> by Thomas Hallgren where he mentioned that PostGre only defines
>> one stack and therefor pl/java has no way of telling PostGre
>> about multiple thread stack pointers.
>>
>> My question is now if there is a patched version available of PostGre
>> 8.3.0 having this stack_depth check disabled?
>
> This was fixed in postgresql/pljava shortly after the referenced
> discussion. As requested, postgresql 8.1+ allows modification of
> stack_base_ptr so pljava can set it as desired.
>
> Kris Jurka
^ permalink raw reply [nested|flat] 11+ messages in thread
* Re: [Pljava-dev] stack depth limit exceeded - patch possible?
@ 2008-04-14 15:23 Kris Jurka <books@ejurka.com>
parent: Alexander Wöhrer <woehrer@par.univie.ac.at>
0 siblings, 1 reply; 11+ messages in thread
From: Kris Jurka @ 2008-04-14 15:23 UTC (permalink / raw)
To: Alexander Wöhrer <woehrer@par.univie.ac.at>; +Cc: pljava-dev@pgfoundry.org; pgsql-hackers@postgresql.org
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
^ permalink raw reply [nested|flat] 11+ messages in thread
* [Pljava-dev] stack depth limit exceeded - patch possible?
@ 2008-04-16 14:36
parent: Kris Jurka <books@ejurka.com>
0 siblings, 1 reply; 11+ messages in thread
From: @ 2008-04-16 14:36 UTC (permalink / raw)
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/
**********************************************
^ permalink raw reply [nested|flat] 11+ messages in thread
* [Pljava-dev] stack depth limit exceeded - patch possible?
@ 2008-04-16 16:16
parent:
0 siblings, 1 reply; 11+ messages in thread
From: @ 2008-04-16 16:16 UTC (permalink / raw)
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;
^ permalink raw reply [nested|flat] 11+ messages in thread
* [Pljava-dev] stack depth limit exceeded - patch possible?
@ 2008-04-17 13:22
parent:
0 siblings, 1 reply; 11+ messages in thread
From: @ 2008-04-17 13:22 UTC (permalink / raw)
Dear Kris,
first of all thank you very much for your fast response including a
patch suggestion for my issue.
I made the changes to the 2 pljava source files (one c File, one java
File changed) as proposed by you, assuming that
*** 153,159 ****
{
synchronized(Backend.THREADLOCK)
{
! return _move(m_pointer, forward, count);
}
}
--- 153,159 ----
{
synchronized(Backend.THREADLOCK)
{
! return _fetch(m_pointer, System.identityHashCode(Thread.currentThread()), forward, count);
}
}
***************
should be changed to the new return _move(.....) as well as done for the return _fetch(...).
As I never built postgresql nor pljava local on my Win XP maschine I installed mingw and msys, set msys\bin in my path and tried to build the pl/java release with
make release
from the root directory of the pljava src distribution (/e/downloads/pljava).
Then I get the following error:
make[1]: Entering directory `/e/downloads/pljava-1.4.0/build/classes/pljava'
javac -source 1.4 -target 1.4 -d . <java sources>
javac: no source files
make[1]: *** [.timestamp] Error 2
make[1]: Leaving directory `/e/downloads/pljava-1.4.0/build/classes/pljava'
make: *** [pljava_all] Error 2
What else do I have to set in order to get the built process working?
Regards,
Alexander
Kris Jurka schrieb:
> 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
>
--
**********************************************
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/
**********************************************
^ permalink raw reply [nested|flat] 11+ messages in thread
* [Pljava-dev] stack depth limit exceeded - patch possible?
@ 2008-04-17 16:10
parent:
0 siblings, 1 reply; 11+ messages in thread
From: @ 2008-04-17 16:10 UTC (permalink / raw)
On Thu, 17 Apr 2008, Alexander W?hrer wrote:
> should be changed to the new return _move(.....) as well as done for the
> return _fetch(...).
Right, good catch.
> As I never built postgresql nor pljava local on my Win XP maschine I
> installed mingw and msys, set msys\bin in my path and tried to build the
> pl/java release with
>
Building on mingw can be tricky because you can't build pljava against the
official 8.3 binaries because they get built with MSVC and don't provide
some of the support files (pgxs) needed to build with mingw. So you've
got to build postgresql first and then build pljava against that. Your
specific error looks like a problem building java code which shouldn't be
affected by the above, so I'm not exactly sure what's going on. Anyways,
the windows build is tricky so I've put up a test release (with my patch
and your fix) here:
http://ejurka.com/pgsql/pljava/wohrer/
Kris Jurka
^ permalink raw reply [nested|flat] 11+ messages in thread
* [Pljava-dev] stack depth limit exceeded - patch possible?
@ 2008-04-21 16:17
parent:
0 siblings, 1 reply; 11+ messages in thread
From: @ 2008-04-21 16:17 UTC (permalink / raw)
Dear Kris,
thank you very much for building a patched version for me -
unfortunatelly I ran into the following problem after replacing the
pljava.jar and pljava.dll with the patched ones from your archive:
4376DEBUG: Added JVM option string
"-Dsqlj.defaultconnection=jdbc:default:connection"
4376DEBUG: Added JVM option string "vfprintf"
4376DEBUG: Added JVM option string "-Xrs"
4376DEBUG: Creating JavaVM
4376DEBUG: JavaVM created
4376DEBUG: Getting Backend class pljava.jar
4376DEBUG: Backend class was there
java.lang.NoSuchMethodError: _fetch
4376WARNING: java.lang.NoSuchMethodError: _fetch
4376DEBUG: Destroying JavaVM...
4376DEBUG: JavaVM destroyed
4376ERROR: Unable to register native methods
4376STATEMENT: select * from evaluate($1, $2 ) as result
984DEBUG: autovacuum: processing database "postgres"
3692DEBUG: autovacuum: processing database "postgres"
4424DEBUG: autovacuum: processing database "postgres"
2408DEBUG: autovacuum: processing database "postgres"
844DEBUG: autovacuum: processing database "postgres"
4444DEBUG: autovacuum: processing database "postgres"
5280DEBUG: autovacuum: processing database "postgres"
6140DEBUG: autovacuum: processing database "postgres"
5780DEBUG: autovacuum: processing database "postgres"
4160DEBUG: autovacuum: processing database "postgres"
4376LOG: could not receive data from client: Unknown winsock error 10061
4376LOG: unexpected EOF on client connection
5540DEBUG: autovacuum: processing database "postgres"
Looks like something went wrong pretty early (as I don't get any output
in my log4j logs I got before) - any suggestions?
Regards,
Alexander
Kris Jurka schrieb:
>
>
> On Thu, 17 Apr 2008, Alexander W?hrer wrote:
>
>> should be changed to the new return _move(.....) as well as done for
>> the return _fetch(...).
>
> Right, good catch.
>
>> As I never built postgresql nor pljava local on my Win XP maschine I
>> installed mingw and msys, set msys\bin in my path and tried to build
>> the pl/java release with
>>
>
> Building on mingw can be tricky because you can't build pljava against
> the official 8.3 binaries because they get built with MSVC and don't
> provide some of the support files (pgxs) needed to build with mingw.
> So you've got to build postgresql first and then build pljava against
> that. Your specific error looks like a problem building java code
> which shouldn't be affected by the above, so I'm not exactly sure
> what's going on. Anyways, the windows build is tricky so I've put up a
> test release (with my patch and your fix) here:
>
> http://ejurka.com/pgsql/pljava/wohrer/
>
> 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/
**********************************************
^ permalink raw reply [nested|flat] 11+ messages in thread
* [Pljava-dev] stack depth limit exceeded - patch possible?
@ 2008-04-21 20:38
parent:
0 siblings, 1 reply; 11+ messages in thread
From: @ 2008-04-21 20:38 UTC (permalink / raw)
On Mon, 21 Apr 2008, Alexander W?hrer wrote:
> Dear Kris,
>
> thank you very much for building a patched version for me -
> unfortunatelly I ran into the following problem after replacing the
> pljava.jar and pljava.dll with the patched ones from your archive:
>
> java.lang.NoSuchMethodError: _fetch
>
There's an explicit binding between the C and Java parts of pljava that I
forgot to update when I changed the function signature for move and fetch
to include the thread id. I've done that and put up a new test release:
http://ejurka.com/pgsql/pljava/wohrer
Kris Jurka
^ permalink raw reply [nested|flat] 11+ messages in thread
* [Pljava-dev] stack depth limit exceeded - patch possible?
@ 2008-04-22 13:26
parent:
0 siblings, 0 replies; 11+ messages in thread
From: @ 2008-04-22 13:26 UTC (permalink / raw)
Dear Kris,
it works :) - at least for my first simple test - will let you know the
results of my more complex test cases.
Regards,
Alexander
Kris Jurka schrieb:
>
>
> On Mon, 21 Apr 2008, Alexander W?hrer wrote:
>
>> Dear Kris,
>>
>> thank you very much for building a patched version for me -
>> unfortunatelly I ran into the following problem after replacing the
>> pljava.jar and pljava.dll with the patched ones from your archive:
>>
>> java.lang.NoSuchMethodError: _fetch
>>
>
> There's an explicit binding between the C and Java parts of pljava
> that I forgot to update when I changed the function signature for move
> and fetch to include the thread id. I've done that and put up a new
> test release:
>
> http://ejurka.com/pgsql/pljava/wohrer
>
> 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/
**********************************************
^ permalink raw reply [nested|flat] 11+ messages in thread
end of thread, other threads:[~2008-04-22 13:26 UTC | newest]
Thread overview: 11+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2008-04-12 18:51 [Pljava-dev] stack depth limit exceeded - patch possible?
2008-04-13 14:25 ` Kris Jurka <books@ejurka.com>
2008-04-14 12:56 ` Alexander Wöhrer <woehrer@par.univie.ac.at>
2008-04-14 15:23 ` Kris Jurka <books@ejurka.com>
2008-04-16 14:36 `
2008-04-16 16:16 `
2008-04-17 13:22 `
2008-04-17 16:10 `
2008-04-21 16:17 `
2008-04-21 20:38 `
2008-04-22 13:26 `
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox