Nothing to do with that. The VACUUM FREEZE is executed on the new database before migrating the old data over; it's there so that the existing data has no trace of any permanent "normal" Xids from the original counter.
Right. That makes sense, and explains why nobody's been screaming in horror as pg_upgrade takes six weeks to slowly freeze their tables ;)
The new cluster has rows created by initdb etc whose visibility information only makes sense in the context of the control state, clog, etc of the new cluster and we're about to clobber that. So they must be frozen.
