Thread: parallel pg installation and functions gotcha

parallel pg installation and functions gotcha

From
Joe Slag
Date:
I've just spent a day trying to migrate my databases from 7.1 to 7.3.2.  Th=
e=20
only problem has been that every time a function was called, I got the=20
following error:

  FATAL:  Pre-7.3 object file made an elog() call.  Recompile.

The problem, I now realize, is that the output of pg_dumpall contains lines=
=20
like=20

CREATE FUNCTION plpgsql_call_handler () RETURNS opaque
    AS '/usr/local/lib/plpgsql.so', 'plpgsql_call_handler'
    LANGUAGE "C";

However, my approach to upgrading involved installing a parallel copy of th=
e=20
pg binaries, in a directory other than /usr/local/.  So my functions were,=
=20
apparently, using the 7.1 plpgsql.so.

My solution: switch the lines in the output of pg_dumpall to point to the=
=20
current plpgsql.so, and restore normally. Everything works now.

A caution in INSTALL's 'If You Are Upgrading' section might be useful for=
=20
others trying to have two different sets of binaries on the same machine.

Re: parallel pg installation and functions gotcha

From
Tom Lane
Date:
Joe Slag <joe.slag@walkerart.org> writes:
> CREATE FUNCTION plpgsql_call_handler () RETURNS opaque
>     AS '/usr/local/lib/plpgsql.so', 'plpgsql_call_handler'
>     LANGUAGE "C";

> My solution: switch the lines in the output of pg_dumpall to point to the
> current plpgsql.so, and restore normally. Everything works now.

The preferred definition nowadays uses a version-independent
reference to the installation's library directory:

CREATE FUNCTION plpgsql_call_handler () RETURNS language_handler
    AS '$libdir/plpgsql', 'plpgsql_call_handler'
    LANGUAGE c;

Unfortunately we were not bright enough to make it like that from day
one, so old dump files are a hazard :-(

            regards, tom lane