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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
