Re: Threaded Python vs. PostGreSQL plpython - Mailing list pgsql-hackers

From Shridhar Daithankar
Subject Re: Threaded Python vs. PostGreSQL plpython
Date
Msg-id 3E803616.19976.2E2BDDB@localhost
Whole thread Raw
In response to Threaded Python vs. PostGreSQL plpython  (Mike Meyer <mwm@mired.org>)
Responses Re: Threaded Python vs. PostGreSQL plpython  (Mike Meyer <mwm@mired.org>)
List pgsql-hackers
On 24 Mar 2003 at 11:45, Mike Meyer wrote:

> In <200303241039.04880.shridhar_daithankar@persistent.co.in>, "Shridhar
Daithankar<shridhar_daithankar@persistent.co.in>"    <shridhar_daithankar@persistent.co.in> typed:
 
> > Well, I believe, if you link a library against libc_r explicitly, then even if 
> > it is loaded by a program which is not linked against it would do.
> > 
> > One problem on freeBSD is that the thread library is C library itself. So if 
> > postgresql is linked against libc.so and libpython is linked against 
> > libc_r.so, then you *might* get symbol collision.
> > 
> > I suggest you try following.
> 
> It's possible you mean something other than what I think you mean by
> "link against", so my replies might not make sense. In which case,
> please be more explicit.

I mean nothing more than adding -lc_r flag in link time option. That is link 
against. Hope this is clear.

> > 1) Link libpython.so against linuxthreads. 
> 
> Ugh. I'd really rather not have a my python depending on
> linuxthreads. That's marginally better than having no threads at all,
> but that's about it. It's not clear it's worth installing the
> linuxthreads port for.

OK let me explain.

> > 2) Link libpython.so explicitly against libc_r.so, in case it depends upon 
> > thread fucntions to be provided by loader program.. Check ldd libpython.so
> 
> I know it depends on thread functions provided by the loader
> program. It lists one of those as missing when I try and do a
> createlang on the shared library built from the installed python.
> 
> Building a shared library from the threaded version and explicitly
> linking in libc_r.so - so that ldd shows libc_r as a requirement -
> causes the server to terminate on a signal 11 when I try and do a
> createlang on plpython.

OK. Let's try to explain what is happening here. You have linked libpython.so 
against libc_r.so. Postgresql is linked against libc.so. These two libraries 
have large number of symbols common between them. It is quite possible that the 
SIGSEGV you are getting is due to some symbol collision.

Now if you link libpython.so against linuxthreads, it *should* work perfectly 
with postgresql because linuxthreads library provides only thread functions. 
libc.so has none of them. So there is no chance of collision and it *should* 
work.

I hope you find this logical. That is the reason I abandoned linuxthreads in 
one of my projects because I could not stably link linuxthreads and libc_r.so 
in same program.

Anyway this is just to get things linked against and running. You can not run 
threaded python apps with such a library because libc against which it is 
linked is not threaded or thread safe.

I consider this as a bit of fault with freeBSD libc. Although I can live with 
it.

OTOH, you can link postgresql and libpython.so with libc_r. That should work as 
well and you can use threads in python too. I would recommend this approach.

HTH


ByeShridhar

--
Bubble Memory, n.:    A derogatory term, usually referring to a person's 
intelligence.    See also "vacuum tube".



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Nested transactions
Next
From: Bruce Momjian
Date:
Subject: Re: updateable cursors & visibility