From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: openbsd, plpython, missing threading symbols |
Date: | 2005-08-03 20:28:21 |
Message-ID: | 42F128E5.3020705@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>Did we recently make some fixes for FBSD that cured the problem with
>>unresolved pthread* symbols for plpython?
>>
>>
>
>No, it's not fixed. I think the owner of the freebsd buildfarm machine
>masked the problem by building an unthreaded libpython.
>
>The only fix that so far looks like it would work is to build the
>backend with threading (CPPFLAGS += -D_THREAD_SAFE and LIBS += -pthread,
>IIUC). This seems sufficiently invasive that I'm quite loath to do it.
>Does anyone have a handle on the likely performance and stability costs
>of doing this on BSDen?
>
>The alternative is to say that plpython isn't supported on BSDen unless
>you choose to build an unthreaded libpython. Unpleasant as that may be,
>I do not care for the proposition that plpython gets to dictate our
>choice of libc. Whatever costs are incurred by that will be paid by
>people who are not even using plpython, and that's not the direction
>I want to see the pain flowing in.
>
>
>
>
I'm OK with that, but if that's what's done I think we should check for
it up front at configure time and not let it fail at run time like we do
now.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Miller | 2005-08-03 20:32:30 | Re: PL/pgSQL: EXCEPTION NOSAVEPOINT |
Previous Message | Tom Lane | 2005-08-03 20:25:30 | Re: PL/pgSQL: EXCEPTION NOSAVEPOINT |