Re: pg_upgrade libraries check

On Sun, May 27, 2012 at 08:48:54AM -0400, Andrew Dunstan wrote:
> 
> >I just realized the problem as part of debugging the report of a problem
> >with plpython_call_handler():
> >
> >    http://archives.postgresql.org/pgsql-hackers/2012-03/msg01101.php
> >    http://archives.postgresql.org/pgsql-bugs/2012-05/msg00205.php
> >
> >The problem is that functions defined in the "pg_catalog" schema, while
> >no explicitly dumped by pg_dump, are implicitly dumped by things like
> >CREATE LANGUAGE plperl.
> >
> >I have added a pg_upgrade C comment documenting this issue in case we
> >revisit it later.
> 
> 
> "things like CREATE LANGUAGE plperl" is a rather vague phrase. The
> PL case could be easily handled by adding this to the query:
> 
>    OR EXISTS (SELECT 1 FROM pg_catalog.pg_language WHERE lanplcallfoid
>    = p.oid)
> 
> 
> Do you know of any other cases that this would miss?

The problem is I don't know.  I don't know in what places we reference
shared object files implicit but not explicitly, and I can't know what
future places we might do this.

> The fact is that unless we do something like this there is a
> potential for unnecessary pg_upgrade failures. The workaround I am
> currently using for the JSON backport of having to supply a dummy
> shared library is almost unspeakably ugly. If you won't consider
> changing the query, how about an option to explicitly instruct
> pg_upgrade to ignore a certain library in its checks?

The plpython_call_handler case I mentioned is a good example of a place
where a pg_upgrade hack to map plpython to plpython2 has caused
pg_upgrade "check" to succeed, but the actual pg_upgrade to fail ---
certainly a bad thing, and something we would like to avoid.  This kind
of tinkering can easily cause such problems.

We are not writing a one-off pg_upgrade for JSON-backpatchers here.  If
you want to create a new pg_upgrade binary with that hack, feel free to
do so. Unless someone can explain a second use case for this, I am not
ready to risk making pg_upgrade more unstable, and I don't think the
community is either.

I am not the person who decides if this gets added to pg_upgrade, but I
am guessing what the community would want here.

FYI, your fix would not address the plpython_call_handler problem
because in that case we are actually dumping that function that
references the shared object, and the pg_dumpall restore will fail.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +