Re: Cannot upgrade from 9.3 to 9.4 using pg_upgrade - Mailing list pgsql-general

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.klaver@aklaver.com

<mailto:adrian.klaver@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.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>

--
Adrian Klaver
adrian.klaver@aklaver.com