On Sun, Jun 4, 2017 at 01:20:12PM -0400, Alvaro Herrera wrote: > Bruce Momjian wrote: > > I have seen a few reports where people are getting this pg_upgrade > > error: > > > > Your installation references loadable libraries that are missing > > from the new installation. You can add these libraries to the > > new installation, or remove the functions using them from the > > old installation. A list of problem libraries is in the file: > > > > ./loadable_libraries.txt > > > > and the file contains: > > > > could not load library "$libdir/pgpool-regclass": > > ERROR: could not access file "$libdir/pgpool-regclass": No such file > > or directory > > > > The problem is that there is no indicate of which database to look in. > > I think it'd be better to be exhaustive about the report, i.e. report > all problems in all databases, if possible. Doing repeated pg_upgrade > attempts until you've nailed all the problems is boring ...
Well, I think there are three open items: * should we print all the database names involved * should we print all the pg_proc.pronames that are involved, not just the unique library names * should we output a query helping people find the pg_proc entries I think there are many cases where DROP EXTENSION XXX fixes the problem, and in those cases showing pg_proc.pronames or giving them a query to find them is a negative --- they should be pointed to DROP EXTENSION. Can we detect when to recommend one over the other? Can we tell which proc entries will not be in the dump and can be ignored? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers