Re: Making plpython 2 and 3 coexist a bit better

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                             +