Re: pg_upgrade from 9.3 to 9.4 fails

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 10/5/15, 1:24 PM, "Bruce Momjian" <bruce@xxxxxxxxxx> 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@xxxxxxxxxx>        http://momjian.us
>  EnterpriseDB                             http://enterprisedb.com
>
>+ As you are, so once was I. As I am, so you will be. +
>+ Roman grave inscription                             +



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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux