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