Skip site navigation (1) Skip section navigation (2)

Re: pg_upgrade with plpython is broken

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>,pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade with plpython is broken
Date: 2012-01-19 22:04:53
Message-ID: 20120119220453.GB26100@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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(at)gmx(dot)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/plpython2
	 plpython_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(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

In response to

Responses

pgsql-hackers by date

Next:From: Greg SmithDate: 2012-01-19 22:23:52
Subject: Re: Vacuum rate limit in KBps
Previous:From: Robert HaasDate: 2012-01-19 21:12:13
Subject: Re: JSON for PG 9.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group