From: | Kris Jurka <books(at)ejurka(dot)com> |
---|---|
To: | Alexander Wöhrer <woehrer(at)par(dot)univie(dot)ac(dot)at> |
Cc: | pljava-dev(at)pgfoundry(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Pljava-dev] stack depth limit exceeded - patch possible? |
Date: | 2008-04-14 15:23:46 |
Message-ID: | Pine.BSO.4.64.0804141112330.5378@leary.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pljava-dev |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Csaba Nagy | 2008-04-14 15:30:40 | Re: Cached Query Plans (was: global prepared statements) |
Previous Message | Andrew Dunstan | 2008-04-14 15:18:49 | pg_dump object sorting |
From | Date | Subject | |
---|---|---|---|
Next Message | Manuel | 2008-04-14 19:31:06 | [Pljava-dev] NoClassDefFoundError? |
Previous Message | Alexander Wöhrer | 2008-04-14 12:56:51 | Re: [Pljava-dev] stack depth limit exceeded - patch possible? |