Re: modifying the tbale function - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: modifying the tbale function
Date
Msg-id 46004CD7.5010609@phlo.org
Whole thread Raw
In response to Re: modifying the tbale function  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> Here is a paper about portable userspace threads that I just googled.
>> http://www.gnu.org/software/pth/rse-pmt.ps
> 
> I'm not impressed --- the list of unsolved problems is a bit too long.
> One that seems a showstopper for our purposes is lack of ability to
> deal reliably with stack overflow on alternate stacks.  If we're going
> to be doing anything as loosely defined as running a third-party
> language interpreter in these stacks, that just won't do.
> 
> Another little problem is it's LGPL.

I don't think using that GnuPT library the paper mentions is a viable
approach for postgres. I just posted that link because it shows
that this is not impossible to do.

What would actually be interesting is to find out of the
ucontext/getcontext/makecontext/swapcontext/setcontext
functions mentioned in the paper are available on the
plattform where postgres is used in production for larger
dataset. I'd assume that people who need this PL optimization
will run a quite update-to-date version of their particular OS,
so maybe the portability problems of those functions wouldn't
be a problem for postgres - the PL optimization would just be
disabled at configure time if they are not available.

The main question is: IF the stability problems like stack overflow
can be addressed, would this be in principle considered to be feature
that people would like to have? Or is it considered not worth the effort?

greetings, Florian Pflug



pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: Money type todos?
Next
From: Chris Travers
Date:
Subject: Question about the TODO, numerics, and division