Fix bogus logic for checking executables' versions within pg_upgrade.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 9 Nov 2017 16:30:30 +0000 (11:30 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 9 Nov 2017 16:30:30 +0000 (11:30 -0500)
Somebody messed up a refactoring here.  As it stood, we'd check pg_ctl's
--version output twice for each cluster.  Worse, the first check for the
new cluster's version happened before we'd done any validate_exec checks
there, breaking the check ordering the code intended.

A. Akenteva

Discussion: https://postgr.es/m/f9266a85d918a3cf3a386b5148aee666@postgrespro.ru

src/bin/pg_upgrade/exec.c

index 59ddc16d6b863ed2ccd6dd810982676ff0d95ffe..810a5a0c3c58d52932558ad8e36857ffa1dc30f6 100644 (file)
@@ -382,12 +382,11 @@ check_bin_dir(ClusterInfo *cluster)
        validate_exec(cluster->bindir, "pg_ctl");
 
        /*
-        * Fetch the binary versions after checking for the existence of pg_ctl,
-        * this gives a correct error if the binary used itself for the version
-        * fetching is broken.
+        * Fetch the binary version after checking for the existence of pg_ctl.
+        * This way we report a useful error if the pg_ctl binary used for version
+        * fetching is missing/broken.
         */
-       get_bin_version(&old_cluster);
-       get_bin_version(&new_cluster);
+       get_bin_version(cluster);
 
        /* pg_resetxlog has been renamed to pg_resetwal in version 10 */
        if (GET_MAJOR_VERSION(cluster->bin_version) < 1000)