Prev: [HACKERS] Implementation of Date/Time Input Interpretation
Next: access method: are disk pages mandatory?
From: Robert Haas on 23 Jun 2010 07:17
On Tue, Jun 22, 2010 at 10:41 PM, Chris <rfusca(a)gmail.com> wrote:
> I�received�two errors (described below) in installing 9.0beta2 on Kubuntu
> 10.04 , RhodiumToad on IRC recommended I post them here.
> I did not have a 2.x or 3.x python dev installed, but I was really only
> interested in python3 via plython3u.
> So...
> sudo apt-get install python3-all-dev
> Configure works fine...
> "./configure --with-pgport=5433 --with-python --with-ossp-uuid --with-libxml
> --with-libxslt --with-perl"
> "make" fails while trying to build plpython, Cannot find python.h i
> believe....(I sadly did not save the text of the error and have since
> continued onward. �But it was not finding a file while building plpython. �I
> believe I would have to uninstall a few things to reproduce.)
> So I tried installing the 2.x dev. �After running "sudo apt-get install
> python-all-dev" then "make;make check;sudo make install", it all worke fine.
> However, �when issuing a "createlang plpython3u template1", I get
> "createlang: language installation failed: ERROR: �could not access file
> "$libdir/plpython3": No such file or directory". �But if I "createlang
> plpython2u template1" first, then it will allow "createlang plpython3u
> template1".
> Am I doing something incorrect, or...?
> (As an aside, functions created with LANGUAGE plpython3u appear to work.)

I can reproduce this, here. The problem seems to be that plpython
only build either plpython2.so or plython3.so, but both languages
expect a call handler called plython_call_handler. So once we load
the shared library for one language, the other language just grabs the
same call handler.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 23 Jun 2010 10:30
Robert Haas <robertmhaas(a)gmail.com> writes:
> I can reproduce this, here. The problem seems to be that plpython
> only build either plpython2.so or plython3.so, but both languages
> expect a call handler called plython_call_handler. So once we load
> the shared library for one language, the other language just grabs the
> same call handler.

We had better fix that --- I can definitely foresee installations
wanting to use both plpython2 and plpython3. This'd require a change in
the default contents of pg_pltemplate, though. Does it seem important
enough to bump catversion for?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 23 Jun 2010 10:49
On Wed, Jun 23, 2010 at 10:30 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas(a)gmail.com> writes:
>> I can reproduce this, here. �The problem seems to be that plpython
>> only build either plpython2.so or plython3.so, but both languages
>> expect a call handler called plython_call_handler. �So once we load
>> the shared library for one language, the other language just grabs the
>> same call handler.
>
> We had better fix that --- I can definitely foresee installations
> wanting to use both plpython2 and plpython3. �This'd require a change in
> the default contents of pg_pltemplate, though. �Does it seem important
> enough to bump catversion for?

Yeah, I think so. As for using both plpython2 and plpython3, it looks
to me like right now you can only use one or the other. I think if
you somehow manage to install both, you're really just getting the
same one twice (I have not tested this, however).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 24 Jun 2010 12:56
On Wed, Jun 23, 2010 at 10:49 AM, Robert Haas <robertmhaas(a)gmail.com> wrote:
> On Wed, Jun 23, 2010 at 10:30 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas(a)gmail.com> writes:
>>> I can reproduce this, here. �The problem seems to be that plpython
>>> only build either plpython2.so or plython3.so, but both languages
>>> expect a call handler called plython_call_handler. �So once we load
>>> the shared library for one language, the other language just grabs the
>>> same call handler.
>>
>> We had better fix that --- I can definitely foresee installations
>> wanting to use both plpython2 and plpython3. �This'd require a change in
>> the default contents of pg_pltemplate, though. �Does it seem important
>> enough to bump catversion for?
>
> Yeah, I think so. �As for using both plpython2 and plpython3, it looks
> to me like right now you can only use one or the other. �I think if
> you somehow manage to install both, you're really just getting the
> same one twice (I have not tested this, however).

So, what's the right thing to do here? Should we just fix it so that
creating the second language always fails, or should we try to make it
possible for both of them to coexist (which is probably a lot more
work)?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Peter Eisentraut on 25 Jun 2010 01:57
On ons, 2010-06-23 at 07:17 -0400, Robert Haas wrote:
> I can reproduce this, here. The problem seems to be that plpython
> only build either plpython2.so or plython3.so, but both languages
> expect a call handler called plython_call_handler. So once we load
> the shared library for one language, the other language just grabs the
> same call handler.

The problem is apparently that when CREATE LANGUAGE creates a language
from a pg_pltemplate entry, it creates the proname from the tmplhandler
name, and if it finds a fitting proname entry already, it used that one.
So when you create plpython2 first and plpython3 second, the pg_language
entries of the latter point to the pg_proc entries of the former.

If you fix that up manually (create additional pg_proc entries and fix
the pg_language entries to point there), it works better.



--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2 3 4
Prev: [HACKERS] Implementation of Date/Time Input Interpretation
Next: access method: are disk pages mandatory?