Skip site navigation (1) Skip section navigation (2)

Re: [COMMITTERS] pgsql: Add note that using PL/Python 2 and 3 in the same session will

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Add note that using PL/Python 2 and 3 in the same session will
Date: 2010-07-06 22:15:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On tis, 2010-07-06 at 17:49 -0400, Tom Lane wrote:
>> Crash?  I can see people regarding that as a security problem.  Maybe we
>> need to do something more pro-active to prevent such conflicts?

> I don't see how.  Loading any module that uses the same symbols as
> another already loaded modules can cause the same problem.

The scenario that worries me is that as soon as somebody has created
both plpython2 and plpython3 functions in the same database, he's at
risk of crashes or maybe worse, even if the functions weren't intended
to be used together.

I don't believe that the problem exists, or at least is of anywhere near
the same scope, for ordinary loadable modules.  As was noted earlier,
ordinary modules don't have references to each other, which is why
RTLD_LOCAL would be a good choice if it weren't for Python.  (I assume
that a sane linker will resolve a module's references to itself if
possible, even if there are conflicts elsewhere.)  The reason why Python
has got an issue here is that it has such heavy dependence on add-on
loadable modules, which have references to the core library.
So with two versions loaded, you don't know which one an
add-on module's symbol references will be resolved to.  (I wonder if
that would be fixable with some better use of symbol versioning?  But
that's something for the Python maintainers not us.)

At this point it seems clear to me that we've not adequately thought
through the implications of having two python versions in one
application namespace, and I'm not sure the Python people have either.
I think we need to do something to block that from happening, at least
until we have a plausible way to make it work.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2010-07-06 22:23:39
Subject: Re: Does mbutils.c really need to use L'\0' ?
Previous:From: Andrew DunstanDate: 2010-07-06 21:55:06
Subject: Re: Does mbutils.c really need to use L'\0' ?

pgsql-committers by date

Next:From: Robert HaasDate: 2010-07-06 22:55:26
Subject: pgsql: Make log_temp_files based on kB, and revert docs & comments to
Previous:From: Tom LaneDate: 2010-07-06 22:03:05
Subject: pgsql: Accept slightly grotty coding in in order to keep

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group