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 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.
--
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
