Re: stack depth limit exceeded problem.

Martijn van Oosterhout wrote:

>On Sat, Sep 24, 2005 at 10:34:42AM +0200, Thomas Hallgren wrote:
>
>
>>Oliver Jowett wrote:
>>
>>
>>>I assume this means you have a single lock serializing requests to the
>>>backend?
>>>
>>>
>>>
>>Yes, of course. I also make sure that the main thread cannot return
>>until another thread that is servicing a backend request has completed.
>>There's absolutely no way two threads can execute backend code
>>simultaniously.
>>
>>
>
>Ok, I have a question. PostgreSQL uses sigsetjmp/siglongjmp to handle
>errors in the backend. If you're changing the stack, how do you avoid
>the siglongjmp jumping back to a different stack? Or do you somehow
>avoid this problem altogether?
>
>
All calls use a PG_TRY/PG_CATCH. So yes, I think I avoid that problem
altogether.

>>I though about that. The drawback is that each and every call must spawn
>>a new thread, no matter how trivial that call might be. If you do a
>>select from a table with 10,000 records and execute a function for each
>>record, you get 20,000 context switches. Avoiding that kind of overhead
>>is one of the motivating factors for keeping the VM in-process.
>>
>>
>
>Well, on linux at least context switches are quite cheap.
>
I know. And as I said, I don't rule out such a solution. But however
cheap, there's still a performance penalty and added complexity. I
rather avoid both if I can. At least until I know what the real problem
is with the solution that I propose.

> However, how
>does Java handle the possibility that functions never return. Do you
>wrap each call in a PG_TRY/PG_CATCH to propegate errors?
>
>
Yes. All backend exceptions are cought in a PG_CATCH and then propagated
to Java as a ServerException. If there's no catch in the Java code, they
are "rethrown" by the java_call_handler. This time with jump buffer that
was setup by the backend when it invoked the call_handler.

There's also a barrier that will prevent any further calls from the Java
code once an exception has been thrown by the backend unless that call
was wrapped in a savepoint construct. A savepoint rollback will "unlock"
the barrier (this is not related to the thread issue of course).

Regards,
Thomas Hallgren