Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XHyLi-0001qB-Qg for pgsql-admin@arkaria.postgresql.org; Thu, 14 Aug 2014 16:58:02 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XHyLi-0005rT-3a for pgsql-admin@arkaria.postgresql.org; Thu, 14 Aug 2014 16:58:02 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XHyLf-0005la-Ou for pgsql-admin@postgresql.org; Thu, 14 Aug 2014 16:57:59 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1XHyLc-0004Oh-5I for pgsql-admin@postgresql.org; Thu, 14 Aug 2014 16:57:57 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1XHyLb-0006iK-8B; Thu, 14 Aug 2014 12:57:55 -0400 Date: Thu, 14 Aug 2014 12:57:55 -0400 From: Bruce Momjian To: John Scalia Cc: "pgsql-admin@postgresql.org" Subject: Re: pg_upgrade hangs Message-ID: <20140814165755.GC7858@momjian.us> References: <53EBE4B6.5030904@gmail.com> <20140814024821.GB7858@momjian.us> <53ECB9E5.6000004@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53ECB9E5.6000004@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org On Thu, Aug 14, 2014 at 09:30:13AM -0400, John Scalia wrote: > Well, it's now gotten much worse, and I really do not understand how > this is failing. I started off this morning trying to run pg_grade > with strace in the hope that I could find something hanging up, but > pg-upgrade is now failing and exiting very early. Almost immediately > after reporting "Checking cluster versions ok", it throws a SQL > command failed where it tried to create the temporary table > 'info_rels'. The error is that type "info_rels" already exists. > > My first thought was that a previous attempt had partially succeeded > and left some garbage in the new 9.3 instance. So, I deleted > everything in the 9.3 data directory and did a new initdb there, but > the problem continues to reoccur. I have since checked the old 9.2 > database, including the template1 portion, but I don't see an > info_rels table in any of these. (I checked using "select * from > pg_tables;") I'd really like to know why it's failing here. Where is > it finding this info_rels table and why can't I find it? Is it > deleting it after it spits out this error? And is this table > something that gets repeatedly created and dropped during a > pg_upgrade? Well, you managed to show me nothing, so I can't really help you further. info_rels is an internal C struture so I can't guess what is failing. I suggest you show the error, and read the message and then look in the log file it recommends, if any. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin