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. +
