Date: Mon, 5 Oct 2015 15:02:18 -0400
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
Message-ID: <20151005190218.GD6784@momjian.us>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D23837DE.48514%yguo@cvent.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

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