Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-admin-owner+M42749=pgsql+2Dadmin=arkaria.postgresql.org@postgresql.org>)
 id 1XHv6d-0002XM-AW
 for pgsql-admin@arkaria.postgresql.org; Thu, 14 Aug 2014 13:30:15 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-admin-owner+M42749=pgsql+2Dadmin=arkaria.postgresql.org@postgresql.org>)
 id 1XHv6c-0001Qb-Eq
 for pgsql-admin@arkaria.postgresql.org; Thu, 14 Aug 2014 13:30:14 +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 <jayknowsunix@gmail.com>)
 id 1XHv6b-0001PI-6U
 for pgsql-admin@postgresql.org; Thu, 14 Aug 2014 13:30:13 +0000
Received: from mail-yk0-x22f.google.com ([2607:f8b0:4002:c07::22f])
 by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.80) (envelope-from <jayknowsunix@gmail.com>)
 id 1XHv6X-0000OZ-76
 for pgsql-admin@postgresql.org; Thu, 14 Aug 2014 13:30:11 +0000
Received: by mail-yk0-f175.google.com with SMTP id q200so934497ykb.6
 for <pgsql-admin@postgresql.org>; Thu, 14 Aug 2014 06:30:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=message-id:date:from:user-agent:mime-version:to:cc:subject
 :references:in-reply-to:content-type:content-transfer-encoding;
 bh=M3fPikS5Ez5SdwFWdIpOFf4OZVuERMZXO+9Nz57sOLk=;
 b=Aj8SFhGoXoxdmf2FF86ePJoqq9doPerrxkuh+yeFKfCqXvDwzsIb3U7X2dYV23uFV0
 ZyA4SjHxZW+scQhAY/0YLuDv72yQF9D+XhndEUjorKWBjaygqX8m+7q5+mb8WpDNEirZ
 fTLlhXCeKBR/+WBGnK8/KXkMb4xElAWAN+aVaQfes6s7TqtvU+6rIv2r9KqLdHqHQApy
 X+PzI+EsA1PGdrPeIXhSycDEXoxDVK6wGUoHNYOFagY72yVJKau+cO/ikOgWQbWuWhkf
 dSYthCU30095NsT1Fc6a776gKHUlISXg1g5/OsFlxjRW2vEuPrG0EsP0UTJLCIdw+/rp
 I/PQ==
X-Received: by 10.236.7.109 with SMTP id 73mr14783504yho.148.1408023006658;
 Thu, 14 Aug 2014 06:30:06 -0700 (PDT)
Received: from [192.168.254.3] (h77.89.102.166.static.ip.windstream.net.
 [166.102.89.77])
 by mx.google.com with ESMTPSA id k106sm10515116yhq.49.2014.08.14.06.30.05
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Thu, 14 Aug 2014 06:30:06 -0700 (PDT)
Message-ID: <53ECB9E5.6000004@gmail.com>
Date: Thu, 14 Aug 2014 09:30:13 -0400
From: John Scalia <jayknowsunix@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Bruce Momjian <bruce@momjian.us>
CC: "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Subject: Re: pg_upgrade hangs
References: <53EBE4B6.5030904@gmail.com> <20140814024821.GB7858@momjian.us>
In-Reply-To: <20140814024821.GB7858@momjian.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pg-Spam-Score: -2.0 (--)
List-Archive: <http://archives.postgresql.org/pgsql-admin>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-admin.postgresql.org>
List-Owner: <mailto:pgsql-admin-owner@postgresql.org>
List-Post: <mailto:pgsql-admin@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-admin>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>
X-Mailing-List: pgsql-admin
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

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?

Very confusing,
Jay

On 8/13/2014 10:48 PM, Bruce Momjian wrote:
> On Wed, Aug 13, 2014 at 06:20:38PM -0400, John Scalia wrote:
>> Hi all,
>>
>> My QA folks are doing an upgrade test, migrating a database from 9.2.2 to 9.3.3. By default on CentOS, the databases live at:
>>
>> /var/lib/pgsql/9.2/data & /var/lib/pgsql/9.3/data
>>
>> But, they've decided to move these to /data/postgres-9.2/data and
>> /data/postgres-9.3/data and use symlinks back to the original
>> locations, so they don't have to modify the /etc/init.d scripts.
>> Now, pg_upgrade is just hangs regardless of whether I use the actual
>> physical locations or the symlinked ones. I haven't yet tried
>> attaching "strace" to the process, but is there any reason to
>> believe that the symlinks might be causing the problem? Or do I need
>> to look at something else?
> I have no idea.  I have never heard of that, but I suggest you figure
> out why the hang is happening independent of pg_upgrade.
>



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