pg_upgrade issue solved

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
myfault, 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
mythree 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
standbyservers, 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
getting9.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
updatesare 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_upgradeon 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
thenow 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
thispotential 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