| 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: | Whole Thread | Raw Message | 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? |