On Sun, Jul 17, 2016 at 12:47 AM, Jan Wieck <j...@wi3ck.info> wrote: > > The only thing I can imagine would be that there is another slony cluster > (or > remnants of it) hanging around in the 9.4 installation, possibly in > another database. > > That does reproduce the problem. I ran the new doc/pgbench-tutorial through steps 01, 02 and 03 with a 9.4/2.2.2 installation. Upgraded to 9.4/2.2.5 but left out the UPDATE FUNCTIONS for node 3. I could have created a fourth database and just run INIT CLUSTER against that.
I then installed 9.5/2.2.5 in parallel and the pg_upgrade run looks like this: (venv)[postgres@db1 pgbench-tutorial]$ pg_upgrade -b >> /var/lib/pgsql/test_94/bin -B /var/lib/pgsql/test_95/bin -d >> /opt/pgsql/test_94 -D /opt/pgsql/test_95 -p 54394 -P 54395 -c > > Performing Consistency Checks > > ----------------------------- > > Checking cluster versions ok > > Checking database user is the install user ok > > Checking database connection settings ok > > Checking for prepared transactions ok > > Checking for reg* system OID user data types ok > > Checking for contrib/isn with bigint-passing mismatch ok > > Checking for presence of required libraries fatal > > >> 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 > > >> Failure, exiting > > (venv)[postgres@db1 pgbench-tutorial]$ cat loadable_libraries.txt > > Could not load library "$libdir/slony1_funcs.2.2.2" > > ERROR: could not access file "$libdir/slony1_funcs.2.2.2": No such file >> or directory > > > If I drop the offending database or run UPDATE FUNCTIONS in it, pg_upgrade is happy. Regards, Jan -- Jan Wieck Senior Postgres Architect http://pgblog.wi3ck.info
