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 <br...@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 + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
