From: | Alexander Wöhrer <woehrer(at)par(dot)univie(dot)ac(dot)at> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: stack depth limit exceeded - patch possible? |
Date: | 2008-04-12 20:36:36 |
Message-ID: | 48011D54.2060104@par.univie.ac.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dear Gregory,
Thank you very much for you fast answer and your tips.
What is meant by IIUC?
Actually just one thread is accessing the database - the two others do
send/recieve data.
I will try my luck anyway and try to built PostGre 8.3 without
check_stack_depth doing anything - will let you know what happens for my
application.
Best regards,
Alexander
Gregory Stark schrieb:
> Alexander Wöhrer <woehrer(at)par(dot)univie(dot)ac(dot)at> writes:
>
>
>> 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?
>>
>
> That's only going to be the tip of the iceberg. None of the Postgres internal
> functions are thread-safe, they don't lock any internal data structures except
> those shared with other backends.
>
> If you're going to use Postgres internal API functions then you only have any
> hope of doing so from a single thread. And even then people have run into some
> problems.
>
> You might look into PL/J which IIUC runs the java stack in a second process
> rather than in the server process. Or you could run PL/Java but have it
> communicate with your application over a socket, you could send whole
> serialized objects over.
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-04-12 21:03:30 | Re: stack depth limit exceeded - patch possible? |
Previous Message | Tom Lane | 2008-04-12 20:10:32 | Re: Index AM change proposals, redux |