Hi all,
I determined why my v9.4.0 pg_upgrade was failing while trying to migrate from V9.3.3. I'll fess up that it was really my fault, but I'd like to keep others from having the same
problem. Here's what basically happened:
Earlier this year, the environment my V9.3.3 cluster was running in was upgraded. After that upgrade activity, two of my three database servers could not get their VM's restarted.
We have yet to hear why this is still the case. Anyway, as this cluster originally consisted of one primary and two standby servers, it was now down to just the primary. I had
chosen to not re-create new VMs to serve as V9.3.3 standbys as I was going to create those new standby VMs after getting 9.4.0 installed and running. I also had not done any
re-configuration to the original primary server. Now, as I'm sure you all know, in streaming replication, database updates are first committed on a standby server then on the
primary. It turns out that the activities of pg_upgrade still obey this commit sequence. That is, if you're running pg_upgrade on a streaming replication server, you can really
only run it on a primary (I think) and the cluster must have at least one standby server available and running.
My pg_upgrade was hanging up as it tried to create a new temporary table which the database tried to first commit on the now unavailable standby server. As that didn't exist, the
script just hung there waiting for that commit. So, I'll say "My bad..", but I really wish there was some mention of this potential issue on the documentation for pg_upgrade.
At least that's what I'm seeing, and I'll welcome any comment from the development community.
--
Jay
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
