Re: Cannot upgrade from 9.3 to 9.4 using pg_upgrade

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(dot)klaver(at)aklaver(dot)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(dot)klaver(at)aklaver(dot)com
>> <mailto:adrian(dot)klaver(at)aklaver(dot)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(dot)klaver(at)aklaver(dot)com <mailto:adrian(dot)klaver(at)aklaver(dot)com>
>>
>>
>>
>
> --
> Adrian Klaver
> adrian(dot)klaver(at)aklaver(dot)com
>