Hello Stephen,
>Then you run the rsync, at the /srv level, and all those 'new files' in
>/srv/new_cluster on the primary should get copied over to
>/srv/new_cluster on the replica, while any files which are hard-linked
>between old_cluster and new_cluster should end up as hard links on the
>replica.
>
>Thanks,
Thanks very much for your reply.
We've re-ran our test upgrade this morning just to be certain and we reproduced the same result once again, it appears that the issue is not that the pg_controlfile is hardlinked, but that it exists at all.
The output of pg_controldata shows a different ID on the master and the secondary as you suspected:
Master:
$ ./pg_controldata /var/lib/postgresql/9.6/main
pg_control version number: 960
Catalog version number: 201608131
Database system identifier: 6901965895850147745
Database cluster state: in production
pg_control last modified: Thu 03 Dec 2020 10:11:21 GMT
Secondary:
$ ./pg_controldata /var/lib/postgresql/9.6/main
pg_control version number: 960
Catalog version number: 201608131
Database system identifier: 6901966223447496344
Database cluster state: shut down
pg_control last modified: Thu 03 Dec 2020 09:54:00 GMT
The pg_control file does exist on the secondary 9.6 prior to the rsync because it is created by the initdb command (which is step 4. of the instructions -
https://www.postgresql.org/docs/9.6/pgupgrade.html; we verified that by running `/usr/lib/postgresql/9.6/bin/initdb /var/lib/postgresql/999/main` and it creates a pg_control file).