On Jul 26 2005, Jim C. Nasby wrote:

> On Mon, Jul 25, 2005 at 05:02:02PM -0500, Jim C. Nasby wrote:
> > > Can you try rebuilding python and it's dependencies WITHOUT_THREADS?
> > >
> > > I think that would get us where we need?
>
> Worked:
> http://pgbuildfarm.org/cgi-bin/show_...-26%2015:29:33
>
> So the question now is: how do we fix the issue with threaded python?

how do we get libc_r into the mix on FreeBSD 4.11?

I think that will answer it (IIRC, libc_r has the pthread_* functions in
it).

LER

>

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Larry Rosenman <ler@lerctr.org> writes:
> On Jul 26 2005, Jim C. Nasby wrote:
>> So the question now is: how do we fix the issue with threaded python?

> how do we get libc_r into the mix on FreeBSD 4.11?

A possible compromise is to add -lc_r to LIBS if (a) --enable-python
and (b) platform is one of those known to need it.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

On 2005-07-26, Larry Rosenman <ler@lerctr.org> wrote:
>> So the question now is: how do we fix the issue with threaded python?
>
> how do we get libc_r into the mix on FreeBSD 4.11?

You'd have to build the backend with -pthread.

Including -lc_r explicitly when linking stuff on freebsd will usually
cause things to break because of incorrect link ordering.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

--On tisdag, juli 26, 2005 15.17.57 -0400 Tom Lane <tgl@sss.pgh.pa.us>
wrote:

> Larry Rosenman <ler@lerctr.org> writes:
>> On Jul 26 2005, Jim C. Nasby wrote:
>>> So the question now is: how do we fix the issue with threaded python?
>
>> how do we get libc_r into the mix on FreeBSD 4.11?
>
> A possible compromise is to add -lc_r to LIBS if (a) --enable-python
> and (b) platform is one of those known to need it.
>
> regards, tom lane


I think most people use the ports when using postgresql with FreeBSD.

There are a bunch of ports, one for the server, another for plpython, yet
another for plperl. Hence, if the ports are used, the server will be
configured separately from the plpython.so, and the above suggestion will
not do. OTH, the port for the server has a bunch of options (opted using
dialog(1)), where one is:

"Link w/ libc_r, used by plpython"

It defaults to off, but it is pretty obvious that if you need plpython, you
should check that option.

If it is on, following happens:

--
..if ${OSVERSION} < 500016
PTHREAD_CFLAGS?= -D_THREAD_SAFE
PTHREAD_LIBS?= -pthread
..elif ${OSVERSION} < 502102
PTHREAD_CFLAGS?= -D_THREAD_SAFE
PTHREAD_LIBS?= -lc_r
..else
PTHREAD_CFLAGS?=
PTHREAD_LIBS?= -pthread
..endif
--

and then PTHREAD_X are added to X. The pthread switch actually adds -lc_r
to the linking chain:

--
gcc(1) man page excerpt:
FreeBSD SPECIFIC OPTIONS
-pthread
Link a user-threaded process against libc_r instead of libc.
Ob-
jects linked into user-threaded processes should be
compiled
with -D_THREAD_SAFE.
--


See
<http://www.freebsd.org/cgi/cvsweb.cgi/ports/databases/postgresql80-server/Makefile>
for the port's sources.


BTW, I do have 4.11 boxes running SMP, shall I run another test, on SMP?
Tip-of-trunk with --enable-python?

/Palle


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Tue, Jul 26, 2005 at 10:17:05PM +0200, Palle Girgensohn wrote:
> --On tisdag, juli 26, 2005 15.17.57 -0400 Tom Lane <tgl@sss.pgh.pa.us>
> wrote:
>
> >Larry Rosenman <ler@lerctr.org> writes:
> >>On Jul 26 2005, Jim C. Nasby wrote:
> >>>So the question now is: how do we fix the issue with threaded python?
> >
> >>how do we get libc_r into the mix on FreeBSD 4.11?
> >
> >A possible compromise is to add -lc_r to LIBS if (a) --enable-python
> >and (b) platform is one of those known to need it.
> >
> > regards, tom lane
>
>
> I think most people use the ports when using postgresql with FreeBSD.
>
> There are a bunch of ports, one for the server, another for plpython, yet
> another for plperl. Hence, if the ports are used, the server will be
> configured separately from the plpython.so, and the above suggestion will
> not do. OTH, the port for the server has a bunch of options (opted using
> dialog(1)), where one is:
>
> "Link w/ libc_r, used by plpython"
>
> It defaults to off, but it is pretty obvious that if you need plpython, you
> should check that option.
>
> If it is on, following happens:
>
> --
> .if ${OSVERSION} < 500016
> PTHREAD_CFLAGS?= -D_THREAD_SAFE
> PTHREAD_LIBS?= -pthread
> .elif ${OSVERSION} < 502102
> PTHREAD_CFLAGS?= -D_THREAD_SAFE
> PTHREAD_LIBS?= -lc_r
> .else
> PTHREAD_CFLAGS?=
> PTHREAD_LIBS?= -pthread
> .endif
> --

That works for /usr/ports/databases/postgresql*, but IMHO it'd be nice
if the PostgreSQL source just dealt with this...

> BTW, I do have 4.11 boxes running SMP, shall I run another test, on SMP?
> Tip-of-trunk with --enable-python?
>
> /Palle

My buildfarm machine
(http://pgbuildfarm.org/cgi-bin/show_...ctopus&br=HEAD) is
SMP, so if anything we need UP testing.
--
Jim C. Nasby, Database Consultant decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Jim C. Nasby wrote:
>
> My buildfarm machine
> (http://pgbuildfarm.org/cgi-bin/show_...ctopus&br=HEAD)
> is SMP, so if anything we need UP testing.
My UP 4.11-STABLE box is back accessable again.

If someone wants, I can set up another buildfarm member...

LER



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match