Thread: pg_upgrade with plpython is broken
Upgrading an instance containing plpython from <=8.4 to >=9.0 is broken because the module plpython.so was renamed to plpython2.so, and so the pg_upgrade check for loadable libraries fails thus: Your installation references loadable libraries that are missing from the new installation. etc. Installing a symlink fixes the issue. Should we teach pg_upgrade about this renaming, or should we install the symlink as part of the standard installation?
On Mon, Dec 19, 2011 at 10:16 AM, Peter Eisentraut <peter_e@gmx.net> wrote: > Upgrading an instance containing plpython from <=8.4 to >=9.0 is broken > because the module plpython.so was renamed to plpython2.so, and so the > pg_upgrade check for loadable libraries fails thus: > > Your installation references loadable libraries that are missing from the > new installation. etc. > > Installing a symlink fixes the issue. Should we teach pg_upgrade about > this renaming, or should we install the symlink as part of the standard > installation? I feel like this is a pg_upgrade bug, not so much a PL/python problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Dec 22, 2011 at 11:42:23AM -0500, Robert Haas wrote: > On Mon, Dec 19, 2011 at 10:16 AM, Peter Eisentraut <peter_e@gmx.net> wrote: > > Upgrading an instance containing plpython from <=8.4 to >=9.0 is broken > > because the module plpython.so was renamed to plpython2.so, and so the > > pg_upgrade check for loadable libraries fails thus: > > > > Your installation references loadable libraries that are missing from the > > new installation. etc. > > > > Installing a symlink fixes the issue. Should we teach pg_upgrade about > > this renaming, or should we install the symlink as part of the standard > > installation? > > I feel like this is a pg_upgrade bug, not so much a PL/python problem. I looked into this and the problem is coming from the checking of pg_proc library functions (not explicitly _language_ functions): plpython_call_handler | $libdir/plpython2 plpython_inline_handler | $libdir/plpython2plpython_validator | $libdir/plpython2 All three of these entries relate to plpython, and obviously you can see the library name change. The list of required libraries is generated in the old cluster. One interesting solution would be to lookup the matching function names from the new cluster's pg_pltemplate, and use that library name. That would fix the problem of language library files being renamed, but not address non-language library file names being renamed --- there is no _template_ to look for these new values. I hate to add a complex fix for languages and leave the non-language cases unfixed. For that reason, I wonder if I should just hard-code the plpython rename into the pg_upgrade test in check_loadable_libraries(). -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On tor, 2012-01-19 at 17:04 -0500, Bruce Momjian wrote: > For that reason, I wonder if I should just hard-code the plpython > rename into the pg_upgrade test in check_loadable_libraries(). Yes, I haven't come up with a better solution either. If this becomes a general problem, we might need to add a command line option to ignore certain names or something. But not yet.
On Fri, Jan 20, 2012 at 07:01:46AM +0200, Peter Eisentraut wrote: > On tor, 2012-01-19 at 17:04 -0500, Bruce Momjian wrote: > > For that reason, I wonder if I should just hard-code the plpython > > rename into the pg_upgrade test in check_loadable_libraries(). > > Yes, I haven't come up with a better solution either. > > If this becomes a general problem, we might need to add a command line > option to ignore certain names or something. But not yet. Well, the problem is a little more complex than reported. It turns out in PG 9.0 we kept the plpython.so file and symlinked plpython2.so to it. In PG 9.1, we removed plpython.so, and only have plpython2.so, so the problem is with PG >= 9.1, and does not affect 9.0, which explains why we didn't get any 9.0 reports of a problem. I have applied the attached patch to PG head and 9.1 to fix the library checking problem. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +