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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
