From: | Thomas Hallgren <thhal(at)mailblocks(dot)com> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Oliver Jowett <oliver(at)opencloud(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: stack depth limit exceeded problem. |
Date: | 2005-09-24 12:38:35 |
Message-ID: | thhal-0UeEQBM1s8bQ3rKmUoPTBt2LJuu6yC4@mailblocks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 preserves existing
> 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's threaded. 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
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2005-09-24 13:54:11 | Re: stack depth limit exceeded problem. |
Previous Message | Martijn van Oosterhout | 2005-09-24 11:13:00 | Re: stack depth limit exceeded problem. |