On Sat, Sep 24, 2005 at 12:26:58PM +0200, Thomas Hallgren wrote: > 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).
Well, you seem to have dealt with the obvious issues I can see. I imagine you need also to worry about things like signal handling. Is there no way to reserve a stack just for PostgreSQL and switch to that stack, rather than switch threads (although, the stack is really the only thing that differentiates threads anyway...). Linux has sigaltstack so you can catch the stack overflow signal (and other signals obviously, but that's its main use), but it's not terribly portable. What you really need to do is set the stack_base_ptr every time you execute postgres with a new stack; that preserves existing semantics. Signals are the only way the kernel can pass control unexpectedly so if you handle those, postgres would never know it's threaded. I do wonder if there are any other assumptions made... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
pgpAoT6QNSsBT.pgp
Description: PGP signature