Re: [Pgbuildfarm] buildfarm olinguito vs python

From: "Davin M(dot) Potts" <davin(at)discontinuity(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: [Pgbuildfarm] buildfarm olinguito vs python
Date: 2015-05-25 16:38:36
Message-ID: 20150525163836.GN11490@discontinuity.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Alvaro's suggestion, I'm forwarding my questions (see email thread
further below) to this list.

In short, building of PL/Python has been disabled on OpenBSD since 2005.
The errors seen at the time (on OpenBSD and FreeBSD, both) may or may
not still be an issue with modern builds of Python. Can someone point
me to examples of how these errors manifested themselves? Has Peter
Eisentraut or others poked at this recently enough to tell me this is
not worth chasing down?

Thanks for any and all pointers.

Davin

----- Forwarded message from "Davin M. Potts" <davin(at)discontinuity(dot)net> -----

Date: Mon, 25 May 2015 11:12:53 -0500
From: "Davin M. Potts" <davin(at)discontinuity(dot)net>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, "pgbuildfarm(at)lists(dot)commandprompt(dot)com"
<pgbuildfarm(at)lists(dot)commandprompt(dot)com>
Subject: Re: [Pgbuildfarm] buildfarm olinguito vs python

I have rebuilt python to ensure that the relatively new dependency on
the shared-lib is satisfied. This addresses the previous error that
terminated the configure step with the complaint that the shared-lib was
not found.

However, a new complaint is now encountered, complaining that
"threaded Python not supported on this platform" despite the configure
successfully verifying that Python was indeed compiled with thread
support. Looking in python.m4, I see specifically:
---------------
# threaded python is not supported on OpenBSD
AC_MSG_CHECKING(whether Python is compiled with thread support)
pythreads=`${PYTHON} -c "import sys; print(int('thread' in
sys.builtin_module_na
mes))"`
if test "$pythreads" = "1"; then
AC_MSG_RESULT(yes)
case $host_os in
openbsd*)
AC_MSG_ERROR([threaded Python not supported on this platform])
---------------

Looking at the history on python.m4, this has been present for quite a
while, originating back to Bruce Momjian's commits from 2005.

I was convinced that I was able to successfully use the PL/Python
interface on OpenBSD in the past though admittedly I've exclusively
been doing so on other platforms in recent years.

The nature of the errors that were seen back in 2005/2006 are not easily
found. Can somebody point me in the right direction? Or have folks
like Peter Eisentraut tested this recently to verify that the problem
persists with modern builds of Python on OpenBSD? (I can always disable
this test in the configure to see it build but it might not prove much
if I don't try to provoke the previously seen issues.)

Davin

On Tue, May 19, 2015 at 10:55:40AM -0300, Alvaro Herrera wrote:
> Davin M. Potts wrote:
> > It may help to understand that olinguito uses the same build of python
> > (same directory) for happily building all the REL9_X branches and only
> > HEAD seems to have this problem. I have tried cleaning everything (not
> > just cache but blowing away the directories and doing a clean git pull
> > with new, fresh directories) but HEAD's problems persist. If you look
> > back in the history, HEAD used to build happily on this system with this
> > python build. This seems to support the idea that we are looking at a
> > regression.
>
> It's a deliberate change, not a regression. See here:
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=d664a10f9623fd2198b257e513bce849d439a773
>
>
> --
> Álvaro Herrera http://www.twitter.com/alvherre

----- End forwarded message -----

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-05-25 16:41:18 Re: Run pgindent now?
Previous Message Andres Freund 2015-05-25 16:27:48 Re: fsync-pgdata-on-recovery tries to write to more files than previously