Horton

Thread

  1. pg_upgrade with plpython is broken

    Peter Eisentraut <peter_e@gmx.net> — 2011-12-19T15:16:44Z

    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?

  2. Re: pg_upgrade with plpython is broken

    Robert Haas <robertmhaas@gmail.com> — 2011-12-22T16:42:23Z

    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

  3. Re: pg_upgrade with plpython is broken

    Bruce Momjian <bruce@momjian.us> — 2012-01-19T22:04:53Z

    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/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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

  4. Re: pg_upgrade with plpython is broken

    Peter Eisentraut <peter_e@gmx.net> — 2012-01-20T05:01:46Z

    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.

  5. Re: pg_upgrade with plpython is broken

    Bruce Momjian <bruce@momjian.us> — 2012-01-25T03:47:35Z

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