I did manage to get everything working properly yesterday. What I did not first realize is that while pg_upgrade requires both the original server and the new one to be off, if
your original server is the primary in a streaming replication cluster, then the standby(s) must still be running when you start pg_upgrade. The temporary table creation appeared
hung as the primary was waiting on the standby to commit the change, but it wasn't running. After resolving that, I hit another snag where pgpool had a function installed that I
couldn't easily find to remove it. pg_upgrade would fail stating it couldn't find the function's *.so to apply to the new instance. I ended up pulling a pg_dumpall from the
original instance, and manually looked in that to find anything with the name pgpool in it. I then removed those from the Db, and pg_upgrade completed successfully.
Thanks to everyone for their assistance. I just needed to think a little harder on what was happening.
On 1/21/2015 10:46 PM, Bruce Momjian wrote:
On Fri, Jan 16, 2015 at 10:56:19AM -0500, John Scalia wrote:
Hi all,
I'm back to trying to figure out the pg_upgrade stoppage problem on
my V9.4.0 upgrade from V9.3.3. As stated earlier, my environment is
CentOS 6.5 kernel and the server is virtualized, but has been
running 9.3.3 for some time now. I ran pg_upgrade on this system as
follows, I apologize for the length of the message but I putting the
entire screen capture into this. You can see at the end that it got
hung up trying to create a temporary table, but the server has been
on this step for nearly an hour now. It had successfully performed
several queries prior to this, and those were successful.
I suggest you upgrade to V9.3.5 at a minimum. Second, try the why on
its own to see if it works.
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
