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

Re: BUG #5642: pg_upgrade does not handle shared libraries for language handlers

From: "David Platt" <davidplatt(at)davidplatt(dot)com>
To: "'Bruce Momjian'" <bruce(at)momjian(dot)us>, "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5642: pg_upgrade does not handle shared libraries for language handlers
Date: 2010-09-08 02:58:23
Message-ID: 000401cb4f01$b383ec00$1a8bc400$@com (view raw or flat)
Thread:
Lists: pgsql-bugs
No, that was defined in the database through pg_dump, edit the path, the
loading the pg_dump using psql.  For each time the database has been
upgraded.

We started using Postgres in 2000 and even plpgsql had to be created as a
language back then, there was no creation by default.  Evidently the
documentation indicated that the path to the shared library had to be
declared because I don't remember any example showing $library.

-----Original Message-----
From: Bruce Momjian [mailto:bruce(at)momjian(dot)us] 
Sent: Tuesday, September 07, 2010 10:30 PM
To: Tom Lane
Cc: David Platt; pgsql-bugs(at)postgresql(dot)org
Subject: Re: [BUGS] BUG #5642: pg_upgrade does not handle shared libraries
for language handlers

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > David Platt wrote:
> >> The following definition is my database:
> >> 
> >> CREATE FUNCTION plpgsql_call_handler() RETURNS language_handler
> >> LANGUAGE c
> >> AS '/opt/postgres/8.4.1/lib/plpgsql', 'plpgsql_call_handler';
> >> 
> >> The file /opt/postgres/9.rc1/lib/plpgsql.o exists but the pg_upgrade
run
> >> fails on an error loading /opt/postgres/8.4.1/lib/plpgsql.o.
> 
> > What is the error?  What old version of PG are you migrating from?
> 
> Well, it's obviously going to fail, because it will try to load an 8.4
> version of plpgsql.so into 9.0.  The same would happen if you tried to
> pg_dump and reload --- it's by no means the fault of pg_upgrade.
> 
> IMO this is just pilot error.  The call handler should never have been
> declared like that, precisely because the definition will not port to
> other releases or even other installation locations.  The right way for
> the definition to look like is
> 
> 	... AS '$libdir/plpgsql'
> 
> or perhaps even just
> 
> 	... AS 'plpgsql'
> 
> if you'd like to rely on the dynamic_library_path setting.
> 
> I suspect David thinks that pg_upgrade should try to edit the library
> path name, but IMO that would be seriously dangerous, as well as not
> necessary if reasonable practices have been followed.

I am confused how it got defined that way?  Who would be defining their
own plpgsql handler?  I am concerned there is some packaging that is
impoperly defining it.

-- 
  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-bugs by date

Next:From: Tom LaneDate: 2010-09-08 03:16:32
Subject: Re: BUG #5642: pg_upgrade does not handle shared libraries for language handlers
Previous:From: David PlattDate: 2010-09-08 02:50:29
Subject: Re: BUG #5642: pg_upgrade does not handle shared libraries for language handlers

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