From: Bruce Momjian <bruce@momjian.us>
To: Guo, Yun <YGuo@cvent.com>
Cc: pgsql-admin@postgresql.org <pgsql-admin@postgresql.org>
Subject: Re: pg_upgrade from 9.3 to 9.4 fails
Date: Mon, 5 Oct 2015 15:02:18 -0400
Message-ID: <20151005190218.GD6784@momjian.us> (raw)
In-Reply-To: <D23837DE.48514%yguo@cvent.com>
References: <D2381B50.48442%yguo@cvent.com>
<D2381B7B.48445%yguo@cvent.com>
<20151005172418.GA6784@momjian.us>
<D2383215.484EC%yguo@cvent.com>
<20151005180244.GB6784@momjian.us>
<D23833AE.48502%yguo@cvent.com>
<20151005181612.GC6784@momjian.us>
<D23837DE.48514%yguo@cvent.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>
On Mon, Oct 5, 2015 at 06:23:43PM +0000, Guo, Yun wrote:
> >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') ));
>
> Sorry I misunderstood you instruction. I tried this query in all databases
> and it executes without any error.
> I guess that¹s the reason when I have the old server running the check
> could pass.
> However, somehow when the old server is hut down it would fail.
Wow, that is really odd. Can you post the contents of
"pg_upgrade_server.log" after the failure? This file is mentioned in
the error message. You can email it to me privately if it is large.
My only guess is that when the server is running, you have started it
with some special options that pg_upgrade doesn't know about. If the
server is down, pg_upgrade has to start it to check it, and that might
be causing the problem. It would also be good to know if the failure is
with the old or new cluster.
I have never seen a failure like this.
--
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 +
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: bruce@momjian.us, YGuo@cvent.com
Subject: Re: pg_upgrade from 9.3 to 9.4 fails
In-Reply-To: <20151005190218.GD6784@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox