Re: stack depth limit exceeded problem.
От | Thomas Hallgren |
---|---|
Тема | Re: stack depth limit exceeded problem. |
Дата | |
Msg-id | thhal-0UeEQBM1s8bQ3rKmUoPTBt2LJuu6yC4@mailblocks.com обсуждение исходный текст |
Ответ на | Re: stack depth limit exceeded problem. (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: stack depth limit exceeded problem.
|
Список | pgsql-hackers |
Martijn van Oosterhout wrote:> 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.> 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). > What you really need to do is set the stack_base_ptr every> time you execute postgres with a new stack; that preservesexisting> semantics.> Exactly!. What I'd really like to do in threads other than main is: void* currentBase = switchStackBase(stackBaseOfMyThread); PG_TRY { /* service the call here */ switchStackBase(currentBase); } PG_CATCH { switchStackBase(currentBase); /* generate Java exception as usual */ } > Signals are the only way the kernel can pass control unexpectedly so if> you handle those, postgres would never know it'sthreaded. I do wonder> if there are any other assumptions made...>> Have a nice day, You too. And thanks for all your input. Regards, Thomas Hallgren
В списке pgsql-hackers по дате отправления: