Обсуждение: Where art thou, plpython2.dll? (EDB installer)
Hi all I've had some issues with how the procedural languages are packaged in the Windows installer for a while, but I was very surprised to see that plpython2 appears to be entirely absent in 9.3. It doesn't seem to be provided via EDB's StackBuilder app either. What's going on? It looks like it was dropped in 9.1. PL/Python 2 and PL/Python 3 are different things. You can't just upgrade trivially from plpython2 to plpython3. Python 2 and Python 3 install side-by-side without issues. Why isn't plpython2.dll built and included? It's good to see that the required procedural language runtime versions are now included in "installation-notes.html" in the installer, though. Thanks for that. (Any thoughts on my prior question about using virtual service accounts on Windows 7, btw?) -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
I've gone through the same journey myself. Tried to juggle dlls etc. Apparently python 2 is no longer included in the windows installer.
Since I have lots of python 2.x code with native extensions etc, I thought about compiling postgres from source on Windows but as usual the process turned into a nightmare (compiling anything on Windows is, at least for me) There is also the problem of postgres distribution on windows using the activestate version of python distribution instead of the python.org one if my memory is not failing me.
Anyway, I ended up using virtualbox with linux guest because of this issue. If there is an easy way to get python 2.x(7?) working with postgres on windows, it would be nice to hear.
On Tue, Sep 23, 2014 at 9:36 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
Hi all
I've had some issues with how the procedural languages are packaged in
the Windows installer for a while, but I was very surprised to see that
plpython2 appears to be entirely absent in 9.3.
It doesn't seem to be provided via EDB's StackBuilder app either.
What's going on? It looks like it was dropped in 9.1.
PL/Python 2 and PL/Python 3 are different things. You can't just upgrade
trivially from plpython2 to plpython3.
Python 2 and Python 3 install side-by-side without issues.
Why isn't plpython2.dll built and included?
It's good to see that the required procedural language runtime versions
are now included in "installation-notes.html" in the installer, though.
Thanks for that.
(Any thoughts on my prior question about using virtual service accounts
on Windows 7, btw?)
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Craig Ringer <craig <at> 2ndquadrant.com> writes:
> I've had some issues with how the procedural languages are packaged in
> the Windows installer for a while, but I was very surprised to see that
> plpython2 appears to be entirely absent in 9.3.
>
> It doesn't seem to be provided via EDB's StackBuilder app either.
>
> What's going on? It looks like it was dropped in 9.1.
>
> PL/Python 2 and PL/Python 3 are different things. You can't just upgrade
> trivially from plpython2 to plpython3.
>
> Python 2 and Python 3 install side-by-side without issues.
>
> Why isn't plpython2.dll built and included?
>
> It's good to see that the required procedural language runtime versions
> are now included in "installation-notes.html" in the installer, though.
> Thanks for that.
The absence of plpython2 support in Windows builds of 9.3 led to quite a bit of confusion for me especially because the docs seem to make it quite clear that PL/Python 2 is intended to be the default version in standard builds of PostgreSQL both now and for the foreseeable future:
http://www.postgresql.org/docs/9.3/static/plpython-python23.html
(By the way, Craig Ringer and I came across this in a discussion on StackOverflow where we both confirmed that plpython2.dll is absent from the stock installer for PG 9.3. A number of other threads suggest that we're not the only ones who've been stumped by this omission. http://stackoverflow.com/questions/24216627/how-to-install-pl-python-on-postgresql-9-3-x64-windows-7/24218449?noredirect=1#comment40700651_24218449)
Thanks,
Dan Lenski
> I've had some issues with how the procedural languages are packaged in
> the Windows installer for a while, but I was very surprised to see that
> plpython2 appears to be entirely absent in 9.3.
>
> It doesn't seem to be provided via EDB's StackBuilder app either.
>
> What's going on? It looks like it was dropped in 9.1.
>
> PL/Python 2 and PL/Python 3 are different things. You can't just upgrade
> trivially from plpython2 to plpython3.
>
> Python 2 and Python 3 install side-by-side without issues.
>
> Why isn't plpython2.dll built and included?
>
> It's good to see that the required procedural language runtime versions
> are now included in "installation-notes.html" in the installer, though.
> Thanks for that.
The absence of plpython2 support in Windows builds of 9.3 led to quite a bit of confusion for me especially because the docs seem to make it quite clear that PL/Python 2 is intended to be the default version in standard builds of PostgreSQL both now and for the foreseeable future:
http://www.postgresql.org/docs/9.3/static/plpython-python23.html
(By the way, Craig Ringer and I came across this in a discussion on StackOverflow where we both confirmed that plpython2.dll is absent from the stock installer for PG 9.3. A number of other threads suggest that we're not the only ones who've been stumped by this omission. http://stackoverflow.com/questions/24216627/how-to-install-pl-python-on-postgresql-9-3-x64-windows-7/24218449?noredirect=1#comment40700651_24218449)
Thanks,
Dan Lenski
Quoting Seref Arikan <serefarikan@gmail.com>: > > On Tue, Sep 23, 2014 at 9:36 AM, Craig Ringer <craig@2ndquadrant.com> wrote: > >> Hi all >> >> I've had some issues with how the procedural languages are packaged in >> the Windows installer for a while, but I was very surprised to see that >> plpython2 appears to be entirely absent in 9.3. >> >> It doesn't seem to be provided via EDB's StackBuilder app either. >> >> What's going on? It looks like it was dropped in 9.1. >> > > I've gone through the same journey myself. Tried to juggle dlls etc.[...] > > I've struggled with plpython on OpenBSD 5.5-amd64 as well. Could it be related? Maybe the amount of dependencies python pulls in gets overwhelming and things break? $ psql -h localhost -d postgres psql (9.3.2) Type "help" for help. postgres=# create language plpython2u; ERROR: could not load library "/usr/local/lib/postgresql/plpython2.so": dlopen (/usr/local/lib/postgresql/plpython2.so) failed: Cannot load specified object postgres=# create language plperl; CREATE LANGUAGE postgres=# This is strange because /usr/local/lib/postgresql/plpython2.so exists. Also, perl loads fine. $ ls -l /usr/local/lib/postgresql/pl* -rwxr-xr-x 1 root bin 100948 Jul 31 02:05 /usr/local/lib/postgresql/plperl.so -rwxr-xr-x 1 root bin 181287 Jul 31 02:05 /usr/local/lib/postgresql/plpgsql.so -rwxr-xr-x 1 root bin 137951 Mar 4 12:45 /usr/local/lib/postgresql/plpython2.so I uninstalled all the postgres subpackages and rebuilt them from ports, and ended up with an identical plpython2.so, which has these checksums: SHA256 (/usr/local/lib/postgresql/plpython2.so) = 8c7ff6358d9bf0db342e3aca1762cd7c509075a6803b240291d60a21ca38198b MD5 (/usr/local/lib/postgresql/plpython2.so) = bb6122f27f48f0b3672dbc79cef40eea SHA1 (/usr/local/lib/postgresql/plpython2.so) = 4dd79641cbad3f71466648559d74e6b0c4f174a3 Any other OpenBSD users that have run into this, here? -- Nick Guenther 4B Stats/CS University of Waterloo
On Tuesday, September 23, 2014 02:05:48 PM Nick Guenther wrote: > I uninstalled all the postgres subpackages and rebuilt them from > ports, and ended up with an identical plpython2.so, which has these > checksums: > SHA256 (/usr/local/lib/postgresql/plpython2.so) = > 8c7ff6358d9bf0db342e3aca1762cd7c509075a6803b240291d60a21ca38198b > MD5 (/usr/local/lib/postgresql/plpython2.so) = > bb6122f27f48f0b3672dbc79cef40eea > SHA1 (/usr/local/lib/postgresql/plpython2.so) = > 4dd79641cbad3f71466648559d74e6b0c4f174a3 > > Any other OpenBSD users that have run into this, here? I'm not a current BSD user, but I'd suggest ldd'ing that library and see if it has any shared libraries it can't find or if it references shared libraries that are not in whatever OpenBSD uses for a library search path (ie. the equivalent of Linux's ld.so.conf), or if any of those shared libraries have permissions issues.
On 09/23/2014 11:05 AM, Nick Guenther wrote: > > > Quoting Seref Arikan <serefarikan@gmail.com>: >> >> On Tue, Sep 23, 2014 at 9:36 AM, Craig Ringer <craig@2ndquadrant.com> >> wrote: >> >>> Hi all >>> >>> I've had some issues with how the procedural languages are packaged in >>> the Windows installer for a while, but I was very surprised to see that >>> plpython2 appears to be entirely absent in 9.3. >>> >>> It doesn't seem to be provided via EDB's StackBuilder app either. >>> >>> What's going on? It looks like it was dropped in 9.1. >>> >> >> I've gone through the same journey myself. Tried to juggle dlls etc.[...] >> >> > > I've struggled with plpython on OpenBSD 5.5-amd64 as well. Could it be > related? Maybe the amount of dependencies python pulls in gets > overwhelming and things break? > > > $ psql -h localhost -d postgres > psql (9.3.2) > Type "help" for help. > postgres=# create language plpython2u; > ERROR: could not load library "/usr/local/lib/postgresql/plpython2.so": > dlopen (/usr/local/lib/postgresql/plpython2.so) failed: Cannot load > specified object > postgres=# create language plperl; > CREATE LANGUAGE > postgres=# > > What user are you running as? plpythonu is an untrusted language so it can only be installed by a superuser. Also languages are now extensions and should be installed using CREATE EXTENSION: http://www.postgresql.org/docs/9.3/interactive/sql-createlanguage.html > > Any other OpenBSD users that have run into this, here? > -- Adrian Klaver adrian.klaver@aklaver.com
On Tue, Sep 23, 2014 at 11:05 AM, Nick Guenther <nguenthe@uwaterloo.ca> wrote:
> I've struggled with plpython on OpenBSD 5.5-amd64 as well. Could it be related? Maybe the amount of dependencies python pulls in gets overwhelming and things break?
>
>
> $ psql -h localhost -d postgres
> psql (9.3.2)
> Type "help" for help.
> postgres=# create language plpython2u;
> ERROR: could not load library "/usr/local/lib/postgresql/plpython2.so": dlopen (/usr/local/lib/postgresql/plpython2.so) failed: Cannot load specified object
> postgres=# create language plperl;
> CREATE LANGUAGE
> postgres=#
>
>
> This is strange because /usr/local/lib/postgresql/plpython2.so exists. Also, perl loads fine.
> $ ls -l /usr/local/lib/postgresql/pl*
> -rwxr-xr-x 1 root bin 100948 Jul 31 02:05 /usr/local/lib/postgresql/plperl.so
> -rwxr-xr-x 1 root bin 181287 Jul 31 02:05 /usr/local/lib/postgresql/plpgsql.so
> -rwxr-xr-x 1 root bin 137951 Mar 4 12:45 /usr/local/lib/postgresql/plpython2.so
>
> I've struggled with plpython on OpenBSD 5.5-amd64 as well. Could it be related? Maybe the amount of dependencies python pulls in gets overwhelming and things break?
>
>
> $ psql -h localhost -d postgres
> psql (9.3.2)
> Type "help" for help.
> postgres=# create language plpython2u;
> ERROR: could not load library "/usr/local/lib/postgresql/plpython2.so": dlopen (/usr/local/lib/postgresql/plpython2.so) failed: Cannot load specified object
> postgres=# create language plperl;
> CREATE LANGUAGE
> postgres=#
>
>
> This is strange because /usr/local/lib/postgresql/plpython2.so exists. Also, perl loads fine.
> $ ls -l /usr/local/lib/postgresql/pl*
> -rwxr-xr-x 1 root bin 100948 Jul 31 02:05 /usr/local/lib/postgresql/plperl.so
> -rwxr-xr-x 1 root bin 181287 Jul 31 02:05 /usr/local/lib/postgresql/plpgsql.so
> -rwxr-xr-x 1 root bin 137951 Mar 4 12:45 /usr/local/lib/postgresql/plpython2.so
>
Hmmm... I doubt that this is directly related to the Windows issue, where the shared library simply doesn't exist in the standard installation.
Can anyone confirm whether the plpython2 omission from the Windows builds was intentional? If it is intentional, then a few simple changes would make it easier for users like me to figure out that it's missing, not just misconfigured:
* Make plpythonu point to plpython3u, rather than plpython2u, by default
* Omit plpython2u from the pg_pltemplate catalog, so that this:
CREATE LANGUAGE plpython2u
... would give a more helpful error message:
ERROR: unsupported language "plpython2u"
-Dan