Use "upgrade" in preference over "migrate" in pg_upgrade messages and

documentation.  (Many were left over from the old pg_migrator naming.)

contrib/pg_upgrade/check.c

@@ -184,7 +184,7 @@ issue_warnings(char *sequence_script_file_name)
 void
 output_completion_banner(char *deletion_script_file_name)
 {
-	/* Did we migrate the free space files? */
+	/* Did we copy the free space files? */
 	if (GET_MAJOR_VERSION(old_cluster.major_version) >= 804)
 		pg_log(PG_REPORT,
 			   "| Optimizer statistics is not transferred by pg_upgrade\n"
@@ -213,7 +213,7 @@ check_cluster_versions(void)
 	old_cluster.major_version = get_major_server_version(&old_cluster.major_version_str, CLUSTER_OLD);
 	new_cluster.major_version = get_major_server_version(&new_cluster.major_version_str, CLUSTER_NEW);
 
-	/* We allow migration from/to the same major version for beta upgrades */
+	/* We allow upgrades from/to the same major version for alpha/beta upgrades */
 
 	if (GET_MAJOR_VERSION(old_cluster.major_version) < 803)
 		pg_log(PG_FATAL, "This utility can only upgrade from PostgreSQL version 8.3 and later.\n");
@@ -529,9 +529,9 @@ check_for_isn_and_int8_passing_mismatch(Cluster whichCluster)
 			   "| which rely on the bigint data type.  Your old and\n"
 			   "| new clusters pass bigint values differently so this\n"
 			   "| cluster cannot currently be upgraded.  You can\n"
-			   "| manually migrate data that use \"/contrib/isn\"\n"
+			   "| manually upgrade data that use \"/contrib/isn\"\n"
 			   "| facilities and remove \"/contrib/isn\" from the\n"
-			   "| old cluster and restart the migration.  A list\n"
+			   "| old cluster and restart the upgrade.  A list\n"
 			   "| of the problem functions is in the file:\n"
 			   "| \t%s\n\n", output_path);
 	}
@@ -631,7 +631,7 @@ check_for_reg_data_type_usage(Cluster whichCluster)
 			   "| user tables.  These data types reference system oids that\n"
 			   "| are not preserved by pg_upgrade, so this cluster cannot\n"
 			   "| currently be upgraded.  You can remove the problem tables\n"
-			   "| and restart the migration.  A list of the problem columns\n"
+			   "| and restart the upgrade.  A list of the problem columns\n"
 			   "| is in the file:\n"
 			   "| \t%s\n\n", output_path);
 	}

contrib/pg_upgrade/controldata.c

@@ -26,7 +26,7 @@ static void putenv2(const char *var, const char *val);
  * and then pipe its output. With little string parsing we get the
  * pg_control data.  pg_resetxlog cannot be run while the server is running
  * so we use pg_controldata;  pg_controldata doesn't provide all the fields
- * we need to actually perform the migration, but it provides enough for
+ * we need to actually perform the upgrade, but it provides enough for
  * check mode.	We do not implement pg_resetxlog -n because it is hard to
  * return valid xid data for a running server.
  */
@@ -505,8 +505,8 @@ check_control_data(ControlData *oldctrl,
 			   "\nOld and new pg_controldata date/time storage types do not match.\n");
 
 		/*
-		 * This is a common 8.3 -> 8.4 migration problem, so we are more
-		 * verboase
+		 * This is a common 8.3 -> 8.4 upgrade problem, so we are more
+		 * verbose
 		 */
 		pg_log(PG_FATAL,
 			   "You will need to rebuild the new server with configure\n"

contrib/pg_upgrade/info.c

@@ -313,10 +313,10 @@ get_rel_infos(const DbInfo *dbinfo, RelInfoArr *relarr, Cluster whichCluster)
 
 	/*
 	 * pg_largeobject contains user data that does not appear the pg_dumpall
-	 * --schema-only output, so we have to migrate that system table heap and
+	 * --schema-only output, so we have to upgrade that system table heap and
 	 * index.  Ideally we could just get the relfilenode from template1 but
 	 * pg_largeobject_loid_pn_index's relfilenode can change if the table was
-	 * reindexed so we get the relfilenode for each database and migrate it as
+	 * reindexed so we get the relfilenode for each database and upgrade it as
 	 * a normal user table.
 	 * Order by tablespace so we can cache the directory contents efficiently.
 	 */

contrib/pg_upgrade/option.c

@@ -29,8 +29,7 @@ UserOpts	user_opts;
 /*
  * parseCommandLine()
  *
- *	Parses the command line (argc, argv[]) into the given migratorContext object
- *	and initializes the rest of the object.
+ *	Parses the command line (argc, argv[]) and loads structures
  */
 void
 parseCommandLine(int argc, char *argv[])

contrib/pg_upgrade/pg_upgrade.c

@@ -51,8 +51,8 @@ main(int argc, char **argv)
 	check_new_cluster();
 	report_clusters_compatible();
 
-	pg_log(PG_REPORT, "\nPerforming Migration\n");
-	pg_log(PG_REPORT, "--------------------\n");
+	pg_log(PG_REPORT, "\nPerforming Upgrade\n");
+	pg_log(PG_REPORT, "------------------\n");
 
 	disable_old_cluster();
 	prepare_new_cluster();

contrib/pg_upgrade/relfilenode.c

@@ -231,7 +231,7 @@ transfer_relfile(pageCnvCtx *pageConverter, const char *oldfile,
 	const char *msg;
 
 	if ((user_opts.transfer_mode == TRANSFER_MODE_LINK) && (pageConverter != NULL))
-		pg_log(PG_FATAL, "this migration requires page-by-page conversion, "
+		pg_log(PG_FATAL, "this upgrade requires page-by-page conversion, "
 			   "you must use copy-mode instead of link-mode\n");
 
 	if (user_opts.transfer_mode == TRANSFER_MODE_COPY)

contrib/pg_upgrade/tablespace.c

@@ -25,7 +25,7 @@ init_tablespaces(void)
 	if (os_info.num_tablespaces > 0 &&
 	strcmp(old_cluster.tablespace_suffix, new_cluster.tablespace_suffix) == 0)
 		pg_log(PG_FATAL,
-			   "Cannot migrate to/from the same system catalog version when\n"
+			   "Cannot upgrade to/from the same system catalog version when\n"
 			   "using tablespaces.\n");
 }
 

contrib/pg_upgrade/version.c

@@ -73,7 +73,7 @@ new_9_0_populate_pg_largeobject_metadata(bool check_mode,
 			pg_log(PG_WARNING, "\n"
 				   "| Your installation contains large objects.\n"
 				   "| The new database has an additional large object\n"
-				   "| permission table.  After migration, you will be\n"
+				   "| permission table.  After upgrading, you will be\n"
 				   "| given a command to populate the pg_largeobject\n"
 				   "| permission table with default permissions.\n\n");
 		else

contrib/pg_upgrade/version_old_8_3.c

@@ -97,7 +97,7 @@ old_8_3_check_for_name_data_type_usage(Cluster whichCluster)
 			   "| user tables.  This data type changed its internal\n"
 			   "| alignment between your old and new clusters so this\n"
 			   "| cluster cannot currently be upgraded.  You can\n"
-			   "| remove the problem tables and restart the migration.\n"
+			   "| remove the problem tables and restart the upgrade.\n"
 			   "| A list of the problem columns is in the file:\n"
 			   "| \t%s\n\n", output_path);
 	}
@@ -110,7 +110,7 @@ old_8_3_check_for_name_data_type_usage(Cluster whichCluster)
  * old_8_3_check_for_tsquery_usage()
  *	8.3 -> 8.4
  *	A new 'prefix' field was added to the 'tsquery' data type in 8.4
- *	so migration of such fields is impossible.
+ *	so upgrading of such fields is impossible.
  */
 void
 old_8_3_check_for_tsquery_usage(Cluster whichCluster)
@@ -186,7 +186,7 @@ old_8_3_check_for_tsquery_usage(Cluster whichCluster)
 			   "| This data type added a new internal field between\n"
 			   "| your old and new clusters so this cluster cannot\n"
 			   "| currently be upgraded.  You can remove the problem\n"
-			   "| columns and restart the migration.  A list of the\n"
+			   "| columns and restart the upgrade.  A list of the\n"
 			   "| problem columns is in the file:\n"
 			   "| \t%s\n\n", output_path);
 	}
@@ -328,7 +328,7 @@ old_8_3_rebuild_tsvector_tables(bool check_mode,
 				   "| Your installation contains tsvector columns.\n"
 				   "| The tsvector internal storage format changed\n"
 				   "| between your old and new clusters so the tables\n"
-				   "| must be rebuilt.  After migration, you will be\n"
+				   "| must be rebuilt.  After upgrading, you will be\n"
 				   "| given instructions.\n\n");
 		else
 			pg_log(PG_WARNING, "\n"
@@ -441,7 +441,7 @@ old_8_3_invalidate_hash_gin_indexes(bool check_mode,
 				   "| indexes.  These indexes have different\n"
 				   "| internal formats between your old and new\n"
 				   "| clusters so they must be reindexed with the\n"
-				   "| REINDEX command. After migration, you will\n"
+				   "| REINDEX command. After upgrading, you will\n"
 				   "| be given REINDEX instructions.\n\n");
 		else
 			pg_log(PG_WARNING, "\n"
@@ -571,7 +571,7 @@ old_8_3_invalidate_bpchar_pattern_ops_indexes(bool check_mode,
 				   "| \"bpchar_pattern_ops\".  These indexes have\n"
 				   "| different internal formats between your old and\n"
 				   "| new clusters so they must be reindexed with the\n"
-				   "| REINDEX command.  After migration, you will be\n"
+				   "| REINDEX command.  After upgrading, you will be\n"
 				   "| given REINDEX instructions.\n\n");
 		else
 			pg_log(PG_WARNING, "\n"

doc/src/sgml/pgupgrade.sgml

@@ -9,7 +9,7 @@
 
  <para>
   <application>pg_upgrade</> (formerly called <application>pg_migrator</>) allows data
-  stored in <productname>PostgreSQL</> data files to be migrated to a later <productname>PostgreSQL</>
+  stored in <productname>PostgreSQL</> data files to be upgraded to a later <productname>PostgreSQL</>
   major version without the data dump/reload typically required for
   major version upgrades, e.g. from 8.4.7 to the current major release
   of <productname>PostgreSQL</>.  It is not required for minor version upgrades, e.g. from
@@ -227,7 +227,7 @@ gmake prefix=/usr/local/pgsql.new install
      Install any custom shared object files (or DLLs) used by the old cluster
      into the new cluster, e.g. <filename>pgcrypto.so</filename>, whether they are from <filename>contrib</filename>
      or some other source. Do not install the schema definitions, e.g.
-     <filename>pgcrypto.sql</>, because these will be migrated from the old cluster.
+     <filename>pgcrypto.sql</>, because these will be upgraded from the old cluster.
     </para>
    </step>
 
@@ -277,7 +277,7 @@ NET STOP pgsql-8.3  (<productname>PostgreSQL</> 8.3 and older used a different s
      <application>pg_upgrade</> requires the specification of the old and new cluster's
      data and executable (<filename>bin</>) directories. You can also specify separate
      user and port values, and whether you want the data linked instead of
-     copied (the default). If you use linking, the migration will be much
+     copied (the default). If you use linking, the upgrade will be much
      faster (no data copying), but you will no longer be able to access your
      old cluster once you start the new cluster after the upgrade. See
      <literal>pg_upgrade --help</> for a full list of options.
@@ -303,15 +303,15 @@ pg_upgrade.exe
 </programlisting>
 
      Once started, <command>pg_upgrade</> will verify the two clusters are compatible
-     and then do the migration. You can use <command>pg_upgrade --check</>
+     and then do the upgrade. You can use <command>pg_upgrade --check</>
      to perform only the checks, even if the old server is still
      running. <command>pg_upgrade --check</> will also outline any
-     manual adjustments you will need to make after the migration.
+     manual adjustments you will need to make after the upgrade.
      <command>pg_upgrade</> requires write permission in the current directory.
     </para>
 
     <para>
-     Obviously, no one should be accessing the clusters during the migration.
+     Obviously, no one should be accessing the clusters during the upgrade.
     </para>
 
     <para>
@@ -320,7 +320,7 @@ pg_upgrade.exe
      below. To try <command>pg_upgrade</command> again, you will need to modify the old
      cluster so the pg_upgrade schema restore succeeds. If the problem is a
      contrib module, you might need to uninstall the contrib module from
-     the old cluster and install it in the new cluster after the migration,
+     the old cluster and install it in the new cluster after the upgrade,
      assuming the module is not being used to store user data.
     </para>
    </step>
@@ -335,13 +335,13 @@ pg_upgrade.exe
    </step>
 
    <step>
-    <title>Post-migration processing</title>
+    <title>Post-Upgrade processing</title>
 
     <para>
-     If any post-migration processing is required, pg_upgrade will issue
+     If any post-upgrade processing is required, pg_upgrade will issue
      warnings as it completes. It will also generate script files that must
      be run by the administrator. The script files will connect to each
-     database that needs post-migration processing. Each script should be
+     database that needs post-upgrade processing. Each script should be
      run using:
 
 <programlisting>
@@ -368,7 +368,7 @@ psql --username postgres --file script.sql postgres
     <para>
      Because optimizer statistics are not transferred by <command>pg_upgrade</>, you will
      be instructed to run a command to regenerate that information at the end
-     of the migration.
+     of the upgrade.
     </para>
    </step>
 
@@ -419,9 +419,9 @@ psql --username postgres --file script.sql postgres
         to <filename>$PGDATA/global/pg_control</> and perhaps
         tablespace directories. To reuse the old cluster, remove
         the <filename>.old</> suffix
-        from <filename>$PGDATA/global/pg_control</>. and, if migrating
+        from <filename>$PGDATA/global/pg_control</>. and, if upgrading
         to 8.4 or earlier, remove the tablespace directories created
-        by the migration and remove the <filename>.old</> suffix from
+        by the upgrade and remove the <filename>.old</> suffix from
         the tablespace directory names; then you can restart the old
         cluster.
        </para>
@@ -434,12 +434,12 @@ psql --username postgres --file script.sql postgres
  </sect2>
 
  <sect2>
-  <title>Limitations in Migrating <emphasis>from</> PostgreSQL 8.3</title>
+  <title>Limitations in Upgrading <emphasis>from</> PostgreSQL 8.3</title>
 
   <para>
    Upgrading from PostgreSQL 8.3 has additional restrictions not present
    when upgrading from later PostgreSQL releases.  For example,
-   pg_upgrade will not work for a migration from 8.3 if a user column
+   pg_upgrade will not work for upgrading from 8.3 if a user column
    is defined as:
    <itemizedlist>
     <listitem>
@@ -456,7 +456,7 @@ psql --username postgres --file script.sql postgres
   </para>
 
   <para>
-   You must drop any such columns and migrate them manually.
+   You must drop any such columns and upgrade them manually.
   </para>
 
   <para>
@@ -507,29 +507,29 @@ psql --username postgres --file script.sql postgres
   <title>Notes</title>
 
   <para>
-   <application>pg_upgrade</> does not support migration of databases
+   <application>pg_upgrade</> does not support upgrading of databases
    containing these <type>reg*</> OID-referencing system data types:
    <type>regproc</>, <type>regprocedure</>, <type>regoper</>,
    <type>regoperator</>, <type>regclass</>, <type>regconfig</>, and
-   <type>regdictionary</>.  (<type>regtype</> can be migrated.)
+   <type>regdictionary</>.  (<type>regtype</> can be upgraded.)
   </para>
 
   <para>
    All failure, rebuild, and reindex cases will be reported by
    <application>pg_upgrade</> if they affect your installation;
-   post-migration scripts to rebuild tables and indexes will be
+   post-upgrade scripts to rebuild tables and indexes will be
    generated automatically.
   </para>
 
   <para>
    For deployment testing, create a schema-only copy of the old cluster,
-   insert dummy data, and migrate that.
+   insert dummy data, and upgrade that.
   </para>
 
   <para>
    If you want to use link mode and you don't want your old cluster
    to be modified when the new cluster is started, make a copy of the
-   old cluster and migrate that with link mode. To make a valid copy
+   old cluster and upgrade that with link mode. To make a valid copy
    of the old cluster, use <command>rsync</> to create a dirty
    copy of the old cluster while the server is running, then shut down
    the old server and run <command>rsync</> again to update the copy with any