Re: [HACKERS] [COMMITTERS] pgsql: Add note that using PL/Python 2 and 3 in the same session will
On tis, 2010-07-06 at 18:15 -0400, Tom Lane wrote:
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.
How about this?
Index: src/pl/plpython/plpython.c
===
RCS file: /cvsroot/pgsql/src/pl/plpython/plpython.c,v
retrieving revision 1.145
diff -u -3 -p -r1.145 plpython.c
--- src/pl/plpython/plpython.c 29 Jun 2010 00:18:11 - 1.145
+++ src/pl/plpython/plpython.c 7 Jul 2010 21:04:33 -
@@ -3206,6 +3206,8 @@ PyInit_plpy(void)
#endif
+static const int plpython_python_version = PY_MAJOR_VERSION;
+
/*
* _PG_init() - library load-time initialization
*
@@ -3216,6 +3218,21 @@ _PG_init(void)
{
/* Be sure we do initialization only once (should be redundant now) */
static bool inited = false;
+ const int **version_ptr;
+
+ /* Be sure we don't run Python 2 and 3 in the same session (might crash) */
+ version_ptr = (const int **) find_rendezvous_variable(plpython_python_version);
+ if (!(*version_ptr))
+ *version_ptr = plpython_python_version;
+ else
+ {
+ if (**version_ptr != plpython_python_version)
+ ereport(ERROR,
+ (errmsg(Python major version mismatch in session),
+ errdetail(This session had previously used Python major version %d, and it is now attempting to use Python major version %d.,
+ **version_ptr, plpython_python_version),
+ errhint(Start a new session to use a different Python major version.)));
+ }
if (inited)
return;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Add note that using PL/Python 2 and 3 in the same session will
Peter Eisentraut pete...@gmx.net writes: On tis, 2010-07-06 at 18:15 -0400, Tom Lane wrote: 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. How about this? Yeah, I was going to suggest something involving find_rendezvous_variable to let the two versions of plpython check for each other. But doesn't the error need to be elog(FATAL)? If you just elog(ERROR) then the conflicting version of python.so is already loaded and able to cause problems. elog(FATAL) isn't very desirable maybe but it beats crashing. Minor grammatical nit: I think session has previously used would read better in the errdetail. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Add note that using PL/Python 2 and 3 in the same session will
pet...@postgresql.org (Peter Eisentraut) writes: Log Message: --- Add note that using PL/Python 2 and 3 in the same session will probably crash Crash? I can see people regarding that as a security problem. Maybe we need to do something more pro-active to prevent such conflicts? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Add note that using PL/Python 2 and 3 in the same session will
On tis, 2010-07-06 at 17:49 -0400, Tom Lane wrote: pet...@postgresql.org (Peter Eisentraut) writes: Log Message: --- Add note that using PL/Python 2 and 3 in the same session will probably crash 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Add note that using PL/Python 2 and 3 in the same session will
On Tue, 2010-07-06 at 17:49 -0400, Tom Lane wrote: pet...@postgresql.org (Peter Eisentraut) writes: Log Message: --- Add note that using PL/Python 2 and 3 in the same session will probably crash Crash? I can see people regarding that as a security problem. Maybe we need to do something more pro-active to prevent such conflicts? +1 Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Add note that using PL/Python 2 and 3 in the same session will
Peter Eisentraut pete...@gmx.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 python.so library. So with two python.so 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
