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

From Martijn van Oosterhout
Subject Re: stack depth limit exceeded problem.
Date
Msg-id 20050924100855.GA25542@svana.org
Whole thread Raw
In response to Re: stack depth limit exceeded problem.  (Thomas Hallgren <thhal@mailblocks.com>)
Responses Re: stack depth limit exceeded problem.
List pgsql-hackers
On Sat, Sep 24, 2005 at 10:34:42AM +0200, Thomas Hallgren wrote:
> Oliver Jowett wrote:
> >I assume this means you have a single lock serializing requests to the
> >backend?
> >
> Yes, of course. I also make sure that the main thread cannot return
> until another thread that is servicing a backend request has completed.
> There's absolutely no way two threads can execute backend code
> simultaniously.

Ok, I have a question. PostgreSQL uses sigsetjmp/siglongjmp to handle
errors in the backend. If you're changing the stack, how do you avoid
the siglongjmp jumping back to a different stack? Or do you somehow
avoid this problem altogether?

> I though about that. The drawback is that each and every call must spawn
> a new thread, no matter how trivial that call might be. If you do a
> select from a table with 10,000 records and execute a function for each
> record, you get 20,000 context switches. Avoiding that kind of overhead
> is one of the motivating factors for keeping the VM in-process.

Well, on linux at least context switches are quite cheap. However, how
does Java handle the possibility that functions never return. Do you
wrap each call in a PG_TRY/PG_CATCH to propegate errors?

Tricky issues...
--
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.

pgsql-hackers by date:

Previous
From: Thomas Hallgren
Date:
Subject: Re: stack depth limit exceeded problem.
Next
From: Thomas Hallgren
Date:
Subject: Re: stack depth limit exceeded problem.