On Mon, Jan 11, 2016 at 10:44:42AM -0500, Tom Lane wrote:
> 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.
The fix for that would be for pg_upgrade to change
check_loadable_libraries() to start a new session for each LOAD command.
Would you like that done?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +
