From: "Guo, Yun" <YGuo@cvent.com>
To: Bruce Momjian <bruce@momjian.us>
CC: "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Subject: Re: pg_upgrade from 9.3 to 9.4 fails
Thread-Topic: [ADMIN] pg_upgrade from 9.3 to 9.4 fails
Thread-Index: AQHQ/4mcAUs7p8odSEODO5MGegI4x55dIRKAgABIPQD//8cJgA==
Date: Mon, 5 Oct 2015 18:00:27 +0000
Message-ID: <D2383215.484EC%yguo@cvent.com>
References: <D2381B50.48442%yguo@cvent.com> <D2381B7B.48445%yguo@cvent.com>
 <20151005172418.GA6784@momjian.us>
In-Reply-To: <20151005172418.GA6784@momjian.us>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.5.3.150624
Content-Type: text/plain; charset="us-ascii"
Content-ID: <82265C1635997744BE53E78B72DA029D@cvent.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org


On 10/5/15, 1:24 PM, "Bruce Momjian" <bruce@momjian.us> wrote:

>On Mon, Oct  5, 2015 at 05:05:46PM +0000, Guo, Yun wrote:
>> -bash-4.1$ /usr/pgsql-9.3/bin/pg_ctl stop -D /data/pg.old
>> waiting for server to shut down.... done
>> server stopped
>> -bash-4.1$ pg_upgrade -b /usr/pgsql-9.3/bin -B /usr/pgsql-9.4/bin -d
>>/data/
>> pg.old -D /data/pg --check
>> 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 =3D
>> n.oid LEFT OUTER JOIN pg_catalog.pg_index i   ON c.oid =3D 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=20=20=20=20
>> n.nspname !~ '^pg_toast_temp_' AND     n.nspname NOT IN ('pg_catalog',
>> 'information_schema', 'binary_upgrade', 'pg_toast') AND c.oid >=3D 16384)
>>  OR
>> (n.nspname =3D 'pg_catalog' AND     relname IN ('pg_largeobject',
>> 'pg_largeobject_loid_pn_index', 'pg_largeobject_metadata',
>> 'pg_largeobject_metadata_oid_index') ));
>> ERROR:  cache lookup failed for type 1670699
>
>Wow, that is weird.  Can you run this query on the old cluster and show
>us the output?
>
>	SELECT * FROM pg_type WHERE oid =3D 1670699;

This turns out to be empty in all of the databases:
postgres=3D# SELECT * FROM pg_type WHERE oid =3D 1670699;
 typname | typnamespace | typowner | typlen | typbyval | typtype |
typcategory | typispreferred | typisdefined | typdelim | typrelid | typ
elem | typarray | typinput | typoutput | typreceive | typsend | typmodin |
typmodout | typanalyze | typalign | typstorage | typnotnull | t
ypbasetype | typtypmod | typndims | typcollation | typdefaultbin |
typdefault | typacl
---------+--------------+----------+--------+----------+---------+---------
----+----------------+--------------+----------+----------+----
-----+----------+----------+-----------+------------+---------+----------+-
----------+------------+----------+------------+------------+--
-----------+-----------+----------+--------------+---------------+---------
---+--------
(0 rows)


>
>This query doesn't even query pg_type, so it must be some internal use
>of pg_type.
>
>The reason check doesn't show the failure is that only a non-check run
>collects pg_class.oid values, but we never expect that to fail so we
>don't test it in check mode.
>
>My guess is that something is messed up in your system catalogs.  Can
>you try running this query in each old database and see if it fails.

If my old server system catalog is messed up is there way to repair it?

>
>--=20
>  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
>+ As you are, so once was I. As I am, so you will be. +
>+ Roman grave inscription                             +


--=20
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin