On Sun, Jul 17, 2016 at 12:47 AM, Jan Wieck <jan@xxxxxxxxxx> wrote:
The only thing I can imagine would be that there is another slony cluster (orremnants 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 -cPerforming Consistency Checks-----------------------------Checking cluster versions okChecking database user is the install user okChecking database connection settings okChecking for prepared transactions okChecking for reg* system OID user data types okChecking for contrib/isn with bigint-passing mismatch okChecking for presence of required libraries fatalYour installation references loadable libraries that are missing from thenew installation. You can add these libraries to the new installation,or remove the functions using them from the old installation. A list ofproblem libraries is in the file:loadable_libraries.txtFailure, exiting(venv)[postgres@db1 pgbench-tutorial]$ cat loadable_libraries.txtCould 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.
Jan Wieck
Senior Postgres Architect
Senior Postgres Architect
