Re: stack depth limit exceeded problem. - Mailing list pgsql-hackers

From Thomas Hallgren
Subject Re: stack depth limit exceeded problem.
Date
Msg-id thhal-0CR8SBJtx8bQuxNAUAPm5Old6kLjKw3@mailblocks.com
Whole thread Raw
In response to Re: stack depth limit exceeded problem.  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout wrote:

>>I rely on the signal handler that the JVM uses for page-faults (which a 
>>stack overflow generally amounts to) and fpe exeptions so I know that 
>>they will generate java exceptions in a controlled way (which I in turn 
>>translate to elog(ERROR) on the main thread).
>>    
>>
>
>Well, actually, what I was thinking is if someone sends a -INT or -TERM
>to the backend, which thread will catch it? You have to block it in
>every thread except the one you want to catch it in if you want to
>control it. This means that for any signal handler that PostgreSQL
>installs, you need to intercept it with a wrapper function to make sure
>it runs in the right stack.
>
>Actually, while running backend code, you're probably fine since the
>elog stuff will handle it. But if a signal is received while the JVM is
>running, the signal handler will get the stack of the JVM. Now,
>PostgreSQLs signal handlers tend not to do much so you may be safe.
>They tend not to throws errors, but who knows...
>
>Still, this is all solvable I think...
>  
>
Yes, the signal handling in PL/Java needs a bit more work. Interrupts 
doesn't work well when using PL/Java at present. This is what I plan to 
do (I think this is what you mean too, right?).

Many threads are spawned by the JVM and will never enter the backend. I 
can't control this and I can't add thread initialization code. Hence, I 
have no way of blocking signals on a per-thread basis the normal way. 
Instead, all PostgreSQL handlers that might break when called from 
another thread must be replaced by a wrapper that checks the interrupted 
thread. Since an arbitrary thread will receive the signal, the wrapper 
must sometimes dispatch the signal to another thread. The final receiver 
of the signal must be either the thread that currently executes a 
backend request, or if no such thread exists, the main thread.

PL/Java will be limited to platforms that support that signals are 
dispatched to specific threads. I don't consider that a limitation. I 
think many JVM's have the same restriction.

Regards,
Thomas Hallgren




pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: \x output blowing up
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Vacuum questions...