From: | "Guo, Yun" <YGuo(at)cvent(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade from 9.3 to 9.4 fails |
Date: | 2015-10-05 18:00:27 |
Message-ID: | D2383215.484EC%yguo@cvent.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On 10/5/15, 1:24 PM, "Bruce Momjian" <bruce(at)momjian(dot)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 =
>> 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: 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 = 1670699;
This turns out to be empty in all of the databases:
postgres=# SELECT * FROM pg_type WHERE oid = 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?
>
>--
> Bruce Momjian <bruce(at)momjian(dot)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 +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-10-05 18:02:44 | Re: pg_upgrade from 9.3 to 9.4 fails |
Previous Message | Bruce Momjian | 2015-10-05 17:24:18 | Re: pg_upgrade from 9.3 to 9.4 fails |