From: https://www.postgresql.org/docs/9.6/static/pgupgrade.html
Q1 - Is there a procedure to force this "catch up?" I suppose preventing db activity with a pg_hba hack and running "select pg_switch_xlog()." Maybe there's a better way?
Prepare for standby server upgrades
If you are upgrading standby servers (as outlined in section step 10), verify that the old standby servers are caught up by running pg_controldata against the old primary and standby clusters. Verify that the "Latest checkpoint location" values match in all clusters. (There will be a mismatch if old standby servers were shut down before the old primary.)
Also, if upgrading standby servers, change wal_level to replica in the postgresql.conf file on the new master cluster.
Q2 - I was wondering what the end result is, in general, of this rsync of old and new? If the old db files and upgraded, new db files are meshed what do you get on the other side of the rsync? Again, I mean in general what is the goal?
f. Run rsync
From a directory that is above the old and new database cluster directories, run this for each slave:
rsync --archive --delete --hard-links --size-only old_pgdata new_pgdata remote_dir
where old_pgdata and new_pgdata are relative to the current directory, and remote_dir is above the old and new cluster directories on the standby server. The old and new relative cluster paths must match on the master and standby server.