Commit 803716013dc1350f installed a safeguard against loading plpython2
and plpython3 at the same time, stating
+ It is not allowed to use PL/Python based on Python 2 and PL/Python
+ based on Python 3 in the same session, because the symbols in the
+ dynamic modules would clash, which could result in crashes of the
+ PostgreSQL server process. There is a check that prevents mixing
+ Python major versions in a session, which will abort the session if
+ a mismatch is detected. It is possible, however, to use both
+ PL/Python variants in the same database, from separate sessions.
It turns out though that the freedom promised in the last sentence
is fairly illusory, because if you have functions in both languages
in one DB and you try a dump-and-restore, it will fail.
But it gets worse: a report today in pgsql-general points out that
even if you have the two languages in use *in different databases*,
pg_upgrade will fail, because pg_upgrade rather overenthusiastically
loads every .so mentioned anywhere in the source installation into
one session.
I think we might be able to improve this if we don't do the check in
plpython's _PG_init(), but delay it until we have a need to call into
libpython; which we could skip doing at _PG_init() time, at the cost
of perhaps one more flag check per plpython function call to see if
we've initialized libpython yet.
The behavior would then be that if you load both language .so's
into one session, neither one would be willing to do anything
anymore --- not run a function, and not syntax-check one either,
because any attempted call into either libpython might crash.
But restoring a dump has no need to do either of those things;
it just wants to be able to LOAD the .so. Also, the error for
not being able to do something wouldn't have to be FATAL.
Comments? Am I being too optimistic about whether it's safe to
have both libpythons loaded if we're not calling either of them?
(If I am, we should at least try to improve pg_upgrade so that
it's not imposing a greater restriction than anything else in
the system.)
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
