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"
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");
"| 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);
}
"| 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);
}
* 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.
*/
"\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"
/*
* 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.
*/
/*
* 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[])
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();
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)
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");
}
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
"| 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);
}
* 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)
"| 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);
}
"| 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"
"| 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"
"| \"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"
<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
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>
<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.
</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>
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>
</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>
<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>
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>
</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>
</para>
<para>
- You must drop any such columns and migrate them manually.
+ You must drop any such columns and upgrade them manually.
</para>
<para>
<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
projects / postgresql / commitdiff