Peter Eisentraut writes:
> Why are we using RTLD_GLOBAL?
Some guy named Eisentraut wanted it for plpython:
http://archives.postgresql.org/pgsql-hackers/2001-05/msg00563.php
http://archives.postgresql.org/pgsql-committers/2001-05/msg00283.php
Possibly that no longer applies, though. In general i
On fre, 2010-06-25 at 18:57 -0400, Peter Eisentraut wrote:
> On fre, 2010-06-25 at 23:44 +0200, Andres Freund wrote:
> > Has anybody actually researched if it is safe to run python2 and
> > python3 in the same address space?
>
> You can't run plpython2 and plpython3 in the same session, because th
Tom Lane wrote:
> Bruce Momjian writes:
> > Josh Berkus wrote:
> >>> You could argue it either way. The number of beta testers with
> >>> plpython3 installations is probably very small, so I'm kinda leaning to
> >>> just changing the code without a catversion bump. OTOH, if we want to
> >>> enco
Bruce Momjian writes:
> Josh Berkus wrote:
>>> You could argue it either way. The number of beta testers with
>>> plpython3 installations is probably very small, so I'm kinda leaning to
>>> just changing the code without a catversion bump. OTOH, if we want to
>>> encourage testing of pg_upgrade
Josh Berkus wrote:
>
> > You could argue it either way. The number of beta testers with
> > plpython3 installations is probably very small, so I'm kinda leaning to
> > just changing the code without a catversion bump. OTOH, if we want to
> > encourage testing of pg_upgrade ...
>
> FWIW, the las
On Fri, Jun 25, 2010 at 2:49 PM, Peter Eisentraut wrote:
> On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > The problem is apparently that when CREATE LANGUAGE creates a language
>> > from a pg_pltemplate entry, it creates the proname from the tmplhandler
>> > n
On fre, 2010-06-25 at 23:44 +0200, Andres Freund wrote:
> Has anybody actually researched if it is safe to run python2 and
> python3 in the same address space?
You can't run plpython2 and plpython3 in the same session, because the
libraries are loaded with dlopen(RTLD_GLOBAL) (with RTLD_LOCAL it w
On Wednesday 23 June 2010 16:30:54 Tom Lane wrote:
> Robert Haas 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 shar
> You could argue it either way. The number of beta testers with
> plpython3 installations is probably very small, so I'm kinda leaning to
> just changing the code without a catversion bump. OTOH, if we want to
> encourage testing of pg_upgrade ...
FWIW, the last bump has led to a lot of testin
Peter Eisentraut writes:
> On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote:
>> The fix ought to be to change the function nmes used by plpython3 ...
> Right. What shall we do about the catversion?
You could argue it either way. The number of beta testers with
plpython3 installations is proba
On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > 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 th
Peter Eisentraut writes:
> 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
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,
On Wed, Jun 23, 2010 at 10:49 AM, Robert Haas wrote:
> On Wed, Jun 23, 2010 at 10:30 AM, Tom Lane wrote:
>> Robert Haas 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 c
On Wed, Jun 23, 2010 at 10:30 AM, Tom Lane wrote:
> Robert Haas 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 l
Robert Haas 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 th
On Tue, Jun 22, 2010 at 10:41 PM, Chris 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.
> S
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 work
18 matches
Mail list logo
