Re: [SQL] plpythonu and "hello concurrent world"

[Tom Lane]

Gerardo Herzig <[EMAIL PROTECTED]> writes:
> Hi all. Im having some "problems" with a small concurrent plpython function.

Don't even *think* about starting multiple threads inside the Postgres
backend.  It's an excellent way to break things.

    regards, tom lane
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [HACKERS] Iterating generator from C (PostgreSQL's pl/python RETUN

[Tom Lane]

Hannu Krosing <[EMAIL PROTECTED]> writes:
>> Sven Suursoho wrote:
>>> As for testing in actual pl/python build environment, we had objections 
>>> from 
>>> leading postgresql Tom Lane that even if we do test it at build time, 
>>> a determined DBA may substitute a buggy python.so later and still crash her 
>>> DB instance.

The above is a straw-man depiction of my point.  What I said was that just
because python is up-to-date on the system where plpython is *compiled*
does not mean it'll be up-to-date on the system where plpython is *used*.
With the increasing popularity of prebuilt packages (rpm, deb, etc),
I think it's folly to use a build-time check for this.

regards, tom lane
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [SQL] compiling plpython compilation error

[Tom Lane]

Gerardo Herzig <[EMAIL PROTECTED]> writes:
> Hi all. Im having a hard time trying to compile the plpython package.
> This is the error make gives me:

> /usr/lib/python2.5/config/libpython2.5.a(abstract.o): relocation 
> R_X86_64_32 against `a local symbol' can not be used when making a 
> shared object; recompile with -fPIC

Well, I'd try following the error message's advice: use -fPIC not
-fpic.  Note that it's not real clear whether this needs to be done
for plpython, or libpython, or perhaps both; so you might well be
in for making a custom libpython installation.

regards, tom lane
-- 
http://mail.python.org/mailman/listinfo/python-list