Nothing useful. I'm just going to give up and use pg_dump to a new machine. Hopefully that allows me to bypass this issue.
On Mon, Jan 4, 2016 at 4:58 PM, Adrian Klaver <adrian.kla...@aklaver.com> wrote: > On 01/04/2016 12:53 PM, Arthur Pemberton wrote: > >> Yes, I have tried it without --jobs, just to simplify. >> >> > That would have been too easy. Not sure what is going on. > > So are there any other errors, warnings, etc between?: > > Checking cluster versions ok > > and > > SQL command failed > > > >> On Sun, Jan 3, 2016 at 4:27 PM, Adrian Klaver <adrian.kla...@aklaver.com >> <mailto:adrian.kla...@aklaver.com>> wrote: >> >> On 01/03/2016 12:03 AM, Arthur Pemberton wrote: >> >> I'm trying to use pg_upgrade to upgrade from 9.3 to 9.4 on >> CentOS 6 with >> packages from Postgres' yum repo. >> >> I've revered to vanlla ph_hda.conf on 9.3, and ran initdb on 9.4. >> I >> don't get very far however, I get the following error, and Google >> doesn't seem to help. >> >> -bash-4.1$ /usr/pgsql-9.4/bin/pg_upgrade --jobs 4 \ >> > --old-datadir "/var/lib/pgsql/9.3/data" \ >> > --new-datadir "/var/lib/pgsql/9.4/data" \ >> > --old-bindir "/usr/pgsql-9.3/bin" \ >> > --new-bindir "/usr/pgsql-9.4/bin" >> Performing Consistency Checks >> ----------------------------- >> Checking cluster versions ok >> SQL command failed >> CREATE TEMPORARY TABLE info_rels (reloid) AS SELECT c.oid FROM >> pg_catalog.pg_class c JOIN pg_catalog.pg_namespace n ON >> c.relnamespace = n.oid LEFT OUTER JOIN pg_catalog.pg_index i >> ON c.oid = i.indexrelid WHERE relkind IN ('r', 'm', 'i', 'S') AND >> i.indisvalid IS DISTINCT FROM false AND i.indisready IS >> DISTINCT FROM >> false AND ((n.nspname !~ '^pg_temp_' AND n.nspname !~ >> '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', >> 'information_schema', 'binary_upgrade', 'pg_toast') >> AND >> c.oid >= 16384) OR (n.nspname = 'pg_catalog' AND >> relname IN >> ('pg_largeobject', 'pg_largeobject_loid_pn_index', >> 'pg_largeobject_metadata', 'pg_largeobject_metadata_oid_index') >> )); >> ERROR: relation "info_rels" already exists >> >> Failure, exiting >> >> >> >> Hmm, the error message is fairly clear, the reason for it, not. >> >> Given that it seems to be the program walking over itself, have you >> tried without the --jobs argument? >> >> >> Also what is the results from pg_config for the 9.3 and 9.4 clusters? >> >> www.postgresql.org/docs/9.4/interactive/app-pgconfig.html >> <http://www.postgresql.org/docs/9.4/interactive/app-pgconfig.html> >> >> >> >> Please advise, >> Arthur Pemberton >> >> >> >> -- >> Adrian Klaver >> adrian.kla...@aklaver.com <mailto:adrian.kla...@aklaver.com> >> >> >> > > -- > Adrian Klaver > adrian.kla...@aklaver.com >
