Re: stack depth limit exceeded problem.

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(at)svana(dot)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.