From 9fa8b0ee90c44c0f97d16bf65e94322988c94864 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Tue, 10 Mar 2015 22:33:25 -0400 Subject: Move pg_upgrade from contrib/ to src/bin/ Reviewed-by: Michael Paquier --- doc/src/sgml/contrib.sgml | 1 - doc/src/sgml/filelist.sgml | 1 - doc/src/sgml/pgupgrade.sgml | 723 ---------------------------------------- doc/src/sgml/ref/allfiles.sgml | 1 + doc/src/sgml/ref/pgupgrade.sgml | 715 +++++++++++++++++++++++++++++++++++++++ doc/src/sgml/reference.sgml | 1 + 6 files changed, 717 insertions(+), 725 deletions(-) delete mode 100644 doc/src/sgml/pgupgrade.sgml create mode 100644 doc/src/sgml/ref/pgupgrade.sgml (limited to 'doc/src') diff --git a/doc/src/sgml/contrib.sgml b/doc/src/sgml/contrib.sgml index 57730955bfa..adc21843db2 100644 --- a/doc/src/sgml/contrib.sgml +++ b/doc/src/sgml/contrib.sgml @@ -204,7 +204,6 @@ pages. &pgstandby; &pgtestfsync; &pgtesttiming; - &pgupgrade; &pgxlogdump; diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml index ab935a6664f..2d7514c3ea1 100644 --- a/doc/src/sgml/filelist.sgml +++ b/doc/src/sgml/filelist.sgml @@ -136,7 +136,6 @@ - diff --git a/doc/src/sgml/pgupgrade.sgml b/doc/src/sgml/pgupgrade.sgml deleted file mode 100644 index 45bceff9bea..00000000000 --- a/doc/src/sgml/pgupgrade.sgml +++ /dev/null @@ -1,723 +0,0 @@ - - - - - pg_upgrade - - - - pg_upgrade - 1 - Application - - - - pg_upgrade - upgrade a PostgreSQL server instance - - - - - pg_upgrade - - oldbindir - - newbindir - - olddatadir - - newdatadir - option - - - - - Description - - - pg_upgrade (formerly called pg_migrator) allows data - stored in PostgreSQL data files to be upgraded to a later 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 PostgreSQL. It is not required for minor version upgrades, e.g. from - 9.0.1 to 9.0.4. - - - - Major PostgreSQL releases regularly add new features that often - change the layout of the system tables, but the internal data storage - format rarely changes. pg_upgrade uses this fact - to perform rapid upgrades by creating new system tables and simply - reusing the old user data files. If a future major release ever - changes the data storage format in a way that makes the old data - format unreadable, pg_upgrade will not be usable - for such upgrades. (The community will attempt to avoid such - situations.) - - - - pg_upgrade does its best to - make sure the old and new clusters are binary-compatible, e.g. by - checking for compatible compile-time settings, including 32/64-bit - binaries. It is important that - any external modules are also binary compatible, though this cannot - be checked by pg_upgrade. - - - - pg_upgrade supports upgrades from 8.4.X and later to the current - major release of PostgreSQL, including snapshot and alpha releases. - - - - - Options - - - pg_upgrade accepts the following command-line arguments: - - - - - bindir - bindir - the old PostgreSQL executable directory; - environment variable PGBINOLD - - - - bindir - bindir - the new PostgreSQL executable directory; - environment variable PGBINNEW - - - - - - check clusters only, don't change any data - - - - datadir - datadir - the old cluster data directory; environment - variable PGDATAOLD - - - - datadir - datadir - the new cluster data directory; environment - variable PGDATANEW - - - - - - number of simultaneous processes or threads to use - - - - - - - use hard links instead of copying files to the new - cluster (use junction points on Windows) - - - - options - options - options to be passed directly to the - old postgres command; multiple - option invocations are appended - - - - options - options - options to be passed directly to the - new postgres command; multiple - option invocations are appended - - - - port - port - the old cluster port number; environment - variable PGPORTOLD - - - - port - port - the new cluster port number; environment - variable PGPORTNEW - - - - - - retain SQL and log files even after successful completion - - - - - username - username - cluster's install user name; environment - variable PGUSER - - - - - - enable verbose internal logging - - - - - - display version information, then exit - - - - - - show help, then exit - - - - - - - - - Usage - - - These are the steps to perform an upgrade - with pg_upgrade: - - - - - Optionally move the old cluster - - - If you are using a version-specific installation directory, e.g. - /opt/PostgreSQL/9.1, you do not need to move the old cluster. The - graphical installers all use version-specific installation directories. - - - - If your installation directory is not version-specific, e.g. - /usr/local/pgsql, it is necessary to move the current PostgreSQL install - directory so it does not interfere with the new PostgreSQL installation. - Once the current PostgreSQL server is shut down, it is safe to rename the - PostgreSQL installation directory; assuming the old directory is - /usr/local/pgsql, you can do: - - -mv /usr/local/pgsql /usr/local/pgsql.old - - to rename the directory. - - - - - For source installs, build the new version - - - Build the new PostgreSQL source with configure flags that are compatible - with the old cluster. pg_upgrade will check pg_controldata to make - sure all settings are compatible before starting the upgrade. - - - - - Install the new PostgreSQL binaries - - - Install the new server's binaries and support files. - - - - For source installs, if you wish to install the new server in a custom - location, use the prefix variable: - - -make prefix=/usr/local/pgsql.new install - - - - - Install pg_upgrade - - - Install the pg_upgrade binary in the new PostgreSQL - installation. - - - - - Initialize the new PostgreSQL cluster - - - Initialize the new cluster using initdb. - Again, use compatible initdb - flags that match the old cluster. Many - prebuilt installers do this step automatically. There is no need to - start the new cluster. - - - - - Install custom shared object files - - - Install any custom shared object files (or DLLs) used by the old cluster - into the new cluster, e.g. pgcrypto.so, - whether they are from contrib - or some other source. Do not install the schema definitions, e.g. - pgcrypto.sql, because these will be upgraded from the old cluster. - - - - - Adjust authentication - - - pg_upgrade will connect to the old and new servers several - times, so you might want to set authentication to peer - in pg_hba.conf or use a ~/.pgpass file - (see ). - - - - - Stop both servers - - - Make sure both database servers are stopped using, on Unix, e.g.: - - -pg_ctl -D /opt/PostgreSQL/8.4 stop -pg_ctl -D /opt/PostgreSQL/9.0 stop - - - or on Windows, using the proper service names: - - -NET STOP postgresql-8.4 -NET STOP postgresql-9.0 - - - - - Streaming replication and log-shipping standby servers can remain running until - a later step. - - - - - Run <application>pg_upgrade</> - - - Always run the pg_upgrade binary of the new server, not the old one. - pg_upgrade requires the specification of the old and new cluster's - data and executable (bin) directories. You can also specify - user and port values, and whether you want the data linked instead of - copied (the default). - - - - If you use link mode, the upgrade will be much faster (no file - copying) and use less disk space, but you will not be able to access - your old cluster - once you start the new cluster after the upgrade. Link mode also - requires that the old and new cluster data directories be in the - same file system. (Tablespaces and pg_xlog can be on - different file systems.) See pg_upgrade --help for a full - list of options. - - - - The - - - For Windows users, you must be logged into an administrative account, and - then start a shell as the postgres user and set the proper path: - - -RUNAS /USER:postgres "CMD.EXE" -SET PATH=%PATH%;C:\Program Files\PostgreSQL\9.0\bin; - - - and then run pg_upgrade with quoted directories, e.g.: - - -pg_upgrade.exe - --old-datadir "C:/Program Files/PostgreSQL/8.4/data" - --new-datadir "C:/Program Files/PostgreSQL/9.0/data" - --old-bindir "C:/Program Files/PostgreSQL/8.4/bin" - --new-bindir "C:/Program Files/PostgreSQL/9.0/bin" - - - Once started, pg_upgrade will verify the two clusters are compatible - and then do the upgrade. You can use pg_upgrade --check - to perform only the checks, even if the old server is still - running. pg_upgrade --check will also outline any - manual adjustments you will need to make after the upgrade. If you - are going to be using link mode, you should use the to enable link-mode-specific checks. - pg_upgrade requires write permission in the current directory. - - - - Obviously, no one should be accessing the clusters during the - upgrade. pg_upgrade defaults to running servers - on port 50432 to avoid unintended client connections. - You can use the same port number for both clusters when doing an - upgrade because the old and new clusters will not be running at the - same time. However, when checking an old running server, the old - and new port numbers must be different. - - - - If an error occurs while restoring the database schema, pg_upgrade will - exit and you will have to revert to the old cluster as outlined in - below. To try pg_upgrade 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 upgrade, - assuming the module is not being used to store user data. - - - - - Upgrade Streaming Replication and Log-Shipping standby - servers - - - If you have Streaming Replication () or Log-Shipping () standby servers, follow these steps to - upgrade them (before starting any servers): - - - - - - Install the new PostgreSQL binaries on standby servers - - - Make sure the new binaries and support files are installed on all - standby servers. - - - - - Make sure the new standby data directories do <emphasis>not</> - exist - - - Make sure the new standby data directories do not - exist or are empty. If initdb was run, delete - the standby server data directories. - - - - - Install custom shared object files - - - Install the same custom shared object files on the new standbys - that you installed in the new master cluster. - - - - - Stop standby servers - - - If the standby servers are still running, stop them now using the - above instructions. - - - - - Verify standby servers - - - To prevent old standby servers from being modified, run - pg_controldata against the primary and standby - clusters and verify that the Latest checkpoint location - values match in all clusters. (This requires the standbys to be - shut down after the primary.) - - - - - Save configuration files - - - Save any configuration files from the standbys you need to keep, - e.g. postgresql.conf, recovery.conf, - as these will be overwritten or removed in the next step. - - - - - Start and stop the new master cluster - - - In the new master cluster, change wal_level to - hot_standby in the postgresql.conf file - and then start and stop the cluster. - - - - - Run <application>rsync</> - - - From a directory that is above the old and new database cluster - directories, run this for each slave: - - - rsync --archive --delete --hard-links --size-only old_pgdata new_pgdata remote_dir - - - where - - - If you have tablespaces, you will need to run a similar - rsync command for each tablespace directory. If you - have relocated pg_xlog outside the data directories, - rsync must be run on those directories too. - - - - - Configure streaming replication and log-shipping standby - servers - - - Configure the servers for log shipping. (You do not need to run - pg_start_backup() and pg_stop_backup() - or take a file system backup as the slaves are still synchronized - with the master.) - - - - - - - - - Restore <filename>pg_hba.conf</> - - - If you modified pg_hba.conf, restore its original settings. - It might also be necessary to adjust other configuration files in the new - cluster to match the old cluster, e.g. postgresql.conf. - - - - - Start the new server - - - The new server can now be safely started, and then any - rsync'ed standby servers. - - - - - Post-Upgrade processing - - - 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-upgrade processing. Each script should be - run using: - - -psql --username postgres --file script.sql postgres - - - The scripts can be run in any order and can be deleted once they have - been run. - - - - - In general it is unsafe to access tables referenced in rebuild scripts - until the rebuild scripts have run to completion; doing so could yield - incorrect results or poor performance. Tables not referenced in rebuild - scripts can be accessed immediately. - - - - - - Statistics - - - Because optimizer statistics are not transferred by pg_upgrade, you will - be instructed to run a command to regenerate that information at the end - of the upgrade. You might need to set connection parameters to - match your new cluster. - - - - - Delete old cluster - - - Once you are satisfied with the upgrade, you can delete the old - cluster's data directories by running the script mentioned when - pg_upgrade completes. (Automatic deletion is not - possible if you have user-defined tablespaces inside the old data - directory.) You can also delete the old installation directories - (e.g. bin, share). - - - - - Reverting to old cluster - - - If, after running pg_upgrade, you wish to revert to the old cluster, - there are several options: - - - - - If you ran pg_upgrade - with - - - - - If you ran pg_upgrade - with - - - - - If you ran pg_upgrade without - - - - - - - - - - - Notes - - - pg_upgrade does not support upgrading of databases - containing these reg* OID-referencing system data types: - regproc, regprocedure, regoper, - regoperator, regconfig, and - regdictionary. (regtype can be upgraded.) - - - - All failure, rebuild, and reindex cases will be reported by - pg_upgrade if they affect your installation; - post-upgrade scripts to rebuild tables and indexes will be - generated automatically. If you are trying to automate the upgrade - of many clusters, you should find that clusters with identical database - schemas require the same post-upgrade steps for all cluster upgrades; - this is because the post-upgrade steps are based on the database - schemas, and not user data. - - - - For deployment testing, create a schema-only copy of the old cluster, - insert dummy data, and upgrade that. - - - - If you are upgrading a pre-PostgreSQL 9.2 cluster - that uses a configuration-file-only directory, you must pass the - real data directory location to pg_upgrade, and - pass the configuration directory location to the server, e.g. - -d /real-data-directory -o '-D /configuration-directory'. - - - - If using a pre-9.1 old server that is using a non-default Unix-domain - socket directory or a default that differs from the default of the - new cluster, set PGHOST to point to the old server's socket - location. (This is not relevant on Windows.) - - - - If you want to use link mode and you do not want your old cluster - to be modified when the new cluster is started, make a copy of the - old cluster and upgrade that in link mode. To make a valid copy - of the old cluster, use rsync to create a dirty - copy of the old cluster while the server is running, then shut down - the old server and run rsync --checksum again to update the - copy with any changes to make it consistent. ( - - - - - See Also - - - - - - - - - diff --git a/doc/src/sgml/ref/allfiles.sgml b/doc/src/sgml/ref/allfiles.sgml index 9ae6aecb1a1..211a3c42bd5 100644 --- a/doc/src/sgml/ref/allfiles.sgml +++ b/doc/src/sgml/ref/allfiles.sgml @@ -193,6 +193,7 @@ Complete list of usable sgml source files in this directory. + diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml new file mode 100644 index 00000000000..ce5e3082b5d --- /dev/null +++ b/doc/src/sgml/ref/pgupgrade.sgml @@ -0,0 +1,715 @@ + + + + + pg_upgrade + + + + pg_upgrade + 1 + Application + + + + pg_upgrade + upgrade a PostgreSQL server instance + + + + + pg_upgrade + + oldbindir + + newbindir + + olddatadir + + newdatadir + option + + + + + Description + + + pg_upgrade (formerly called pg_migrator) allows data + stored in PostgreSQL data files to be upgraded to a later 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 PostgreSQL. It is not required for minor version upgrades, e.g. from + 9.0.1 to 9.0.4. + + + + Major PostgreSQL releases regularly add new features that often + change the layout of the system tables, but the internal data storage + format rarely changes. pg_upgrade uses this fact + to perform rapid upgrades by creating new system tables and simply + reusing the old user data files. If a future major release ever + changes the data storage format in a way that makes the old data + format unreadable, pg_upgrade will not be usable + for such upgrades. (The community will attempt to avoid such + situations.) + + + + pg_upgrade does its best to + make sure the old and new clusters are binary-compatible, e.g. by + checking for compatible compile-time settings, including 32/64-bit + binaries. It is important that + any external modules are also binary compatible, though this cannot + be checked by pg_upgrade. + + + + pg_upgrade supports upgrades from 8.4.X and later to the current + major release of PostgreSQL, including snapshot and alpha releases. + + + + + Options + + + pg_upgrade accepts the following command-line arguments: + + + + + bindir + bindir + the old PostgreSQL executable directory; + environment variable PGBINOLD + + + + bindir + bindir + the new PostgreSQL executable directory; + environment variable PGBINNEW + + + + + + check clusters only, don't change any data + + + + datadir + datadir + the old cluster data directory; environment + variable PGDATAOLD + + + + datadir + datadir + the new cluster data directory; environment + variable PGDATANEW + + + + + + number of simultaneous processes or threads to use + + + + + + + use hard links instead of copying files to the new + cluster (use junction points on Windows) + + + + options + options + options to be passed directly to the + old postgres command; multiple + option invocations are appended + + + + options + options + options to be passed directly to the + new postgres command; multiple + option invocations are appended + + + + port + port + the old cluster port number; environment + variable PGPORTOLD + + + + port + port + the new cluster port number; environment + variable PGPORTNEW + + + + + + retain SQL and log files even after successful completion + + + + + username + username + cluster's install user name; environment + variable PGUSER + + + + + + enable verbose internal logging + + + + + + display version information, then exit + + + + + + show help, then exit + + + + + + + + + Usage + + + These are the steps to perform an upgrade + with pg_upgrade: + + + + + Optionally move the old cluster + + + If you are using a version-specific installation directory, e.g. + /opt/PostgreSQL/9.1, you do not need to move the old cluster. The + graphical installers all use version-specific installation directories. + + + + If your installation directory is not version-specific, e.g. + /usr/local/pgsql, it is necessary to move the current PostgreSQL install + directory so it does not interfere with the new PostgreSQL installation. + Once the current PostgreSQL server is shut down, it is safe to rename the + PostgreSQL installation directory; assuming the old directory is + /usr/local/pgsql, you can do: + + +mv /usr/local/pgsql /usr/local/pgsql.old + + to rename the directory. + + + + + For source installs, build the new version + + + Build the new PostgreSQL source with configure flags that are compatible + with the old cluster. pg_upgrade will check pg_controldata to make + sure all settings are compatible before starting the upgrade. + + + + + Install the new PostgreSQL binaries + + + Install the new server's binaries and support + files. pg_upgrade is included in a default installation. + + + + For source installs, if you wish to install the new server in a custom + location, use the prefix variable: + + +make prefix=/usr/local/pgsql.new install + + + + + Initialize the new PostgreSQL cluster + + + Initialize the new cluster using initdb. + Again, use compatible initdb + flags that match the old cluster. Many + prebuilt installers do this step automatically. There is no need to + start the new cluster. + + + + + Install custom shared object files + + + Install any custom shared object files (or DLLs) used by the old cluster + into the new cluster, e.g. pgcrypto.so, + whether they are from contrib + or some other source. Do not install the schema definitions, e.g. + pgcrypto.sql, because these will be upgraded from the old cluster. + + + + + Adjust authentication + + + pg_upgrade will connect to the old and new servers several + times, so you might want to set authentication to peer + in pg_hba.conf or use a ~/.pgpass file + (see ). + + + + + Stop both servers + + + Make sure both database servers are stopped using, on Unix, e.g.: + + +pg_ctl -D /opt/PostgreSQL/8.4 stop +pg_ctl -D /opt/PostgreSQL/9.0 stop + + + or on Windows, using the proper service names: + + +NET STOP postgresql-8.4 +NET STOP postgresql-9.0 + + + + + Streaming replication and log-shipping standby servers can remain running until + a later step. + + + + + Run <application>pg_upgrade</> + + + Always run the pg_upgrade binary of the new server, not the old one. + pg_upgrade requires the specification of the old and new cluster's + data and executable (bin) directories. You can also specify + user and port values, and whether you want the data linked instead of + copied (the default). + + + + If you use link mode, the upgrade will be much faster (no file + copying) and use less disk space, but you will not be able to access + your old cluster + once you start the new cluster after the upgrade. Link mode also + requires that the old and new cluster data directories be in the + same file system. (Tablespaces and pg_xlog can be on + different file systems.) See pg_upgrade --help for a full + list of options. + + + + The + + + For Windows users, you must be logged into an administrative account, and + then start a shell as the postgres user and set the proper path: + + +RUNAS /USER:postgres "CMD.EXE" +SET PATH=%PATH%;C:\Program Files\PostgreSQL\9.0\bin; + + + and then run pg_upgrade with quoted directories, e.g.: + + +pg_upgrade.exe + --old-datadir "C:/Program Files/PostgreSQL/8.4/data" + --new-datadir "C:/Program Files/PostgreSQL/9.0/data" + --old-bindir "C:/Program Files/PostgreSQL/8.4/bin" + --new-bindir "C:/Program Files/PostgreSQL/9.0/bin" + + + Once started, pg_upgrade will verify the two clusters are compatible + and then do the upgrade. You can use pg_upgrade --check + to perform only the checks, even if the old server is still + running. pg_upgrade --check will also outline any + manual adjustments you will need to make after the upgrade. If you + are going to be using link mode, you should use the to enable link-mode-specific checks. + pg_upgrade requires write permission in the current directory. + + + + Obviously, no one should be accessing the clusters during the + upgrade. pg_upgrade defaults to running servers + on port 50432 to avoid unintended client connections. + You can use the same port number for both clusters when doing an + upgrade because the old and new clusters will not be running at the + same time. However, when checking an old running server, the old + and new port numbers must be different. + + + + If an error occurs while restoring the database schema, pg_upgrade will + exit and you will have to revert to the old cluster as outlined in + below. To try pg_upgrade 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 upgrade, + assuming the module is not being used to store user data. + + + + + Upgrade Streaming Replication and Log-Shipping standby + servers + + + If you have Streaming Replication () or Log-Shipping () standby servers, follow these steps to + upgrade them (before starting any servers): + + + + + + Install the new PostgreSQL binaries on standby servers + + + Make sure the new binaries and support files are installed on all + standby servers. + + + + + Make sure the new standby data directories do <emphasis>not</> + exist + + + Make sure the new standby data directories do not + exist or are empty. If initdb was run, delete + the standby server data directories. + + + + + Install custom shared object files + + + Install the same custom shared object files on the new standbys + that you installed in the new master cluster. + + + + + Stop standby servers + + + If the standby servers are still running, stop them now using the + above instructions. + + + + + Verify standby servers + + + To prevent old standby servers from being modified, run + pg_controldata against the primary and standby + clusters and verify that the Latest checkpoint location + values match in all clusters. (This requires the standbys to be + shut down after the primary.) + + + + + Save configuration files + + + Save any configuration files from the standbys you need to keep, + e.g. postgresql.conf, recovery.conf, + as these will be overwritten or removed in the next step. + + + + + Start and stop the new master cluster + + + In the new master cluster, change wal_level to + hot_standby in the postgresql.conf file + and then start and stop the cluster. + + + + + Run <application>rsync</> + + + From a directory that is above the old and new database cluster + directories, run this for each slave: + + + rsync --archive --delete --hard-links --size-only old_pgdata new_pgdata remote_dir + + + where + + + If you have tablespaces, you will need to run a similar + rsync command for each tablespace directory. If you + have relocated pg_xlog outside the data directories, + rsync must be run on those directories too. + + + + + Configure streaming replication and log-shipping standby + servers + + + Configure the servers for log shipping. (You do not need to run + pg_start_backup() and pg_stop_backup() + or take a file system backup as the slaves are still synchronized + with the master.) + + + + + + + + + Restore <filename>pg_hba.conf</> + + + If you modified pg_hba.conf, restore its original settings. + It might also be necessary to adjust other configuration files in the new + cluster to match the old cluster, e.g. postgresql.conf. + + + + + Start the new server + + + The new server can now be safely started, and then any + rsync'ed standby servers. + + + + + Post-Upgrade processing + + + 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-upgrade processing. Each script should be + run using: + + +psql --username postgres --file script.sql postgres + + + The scripts can be run in any order and can be deleted once they have + been run. + + + + + In general it is unsafe to access tables referenced in rebuild scripts + until the rebuild scripts have run to completion; doing so could yield + incorrect results or poor performance. Tables not referenced in rebuild + scripts can be accessed immediately. + + + + + + Statistics + + + Because optimizer statistics are not transferred by pg_upgrade, you will + be instructed to run a command to regenerate that information at the end + of the upgrade. You might need to set connection parameters to + match your new cluster. + + + + + Delete old cluster + + + Once you are satisfied with the upgrade, you can delete the old + cluster's data directories by running the script mentioned when + pg_upgrade completes. (Automatic deletion is not + possible if you have user-defined tablespaces inside the old data + directory.) You can also delete the old installation directories + (e.g. bin, share). + + + + + Reverting to old cluster + + + If, after running pg_upgrade, you wish to revert to the old cluster, + there are several options: + + + + + If you ran pg_upgrade + with + + + + + If you ran pg_upgrade + with + + + + + If you ran pg_upgrade without + + + + + + + + + + + Notes + + + pg_upgrade does not support upgrading of databases + containing these reg* OID-referencing system data types: + regproc, regprocedure, regoper, + regoperator, regconfig, and + regdictionary. (regtype can be upgraded.) + + + + All failure, rebuild, and reindex cases will be reported by + pg_upgrade if they affect your installation; + post-upgrade scripts to rebuild tables and indexes will be + generated automatically. If you are trying to automate the upgrade + of many clusters, you should find that clusters with identical database + schemas require the same post-upgrade steps for all cluster upgrades; + this is because the post-upgrade steps are based on the database + schemas, and not user data. + + + + For deployment testing, create a schema-only copy of the old cluster, + insert dummy data, and upgrade that. + + + + If you are upgrading a pre-PostgreSQL 9.2 cluster + that uses a configuration-file-only directory, you must pass the + real data directory location to pg_upgrade, and + pass the configuration directory location to the server, e.g. + -d /real-data-directory -o '-D /configuration-directory'. + + + + If using a pre-9.1 old server that is using a non-default Unix-domain + socket directory or a default that differs from the default of the + new cluster, set PGHOST to point to the old server's socket + location. (This is not relevant on Windows.) + + + + If you want to use link mode and you do not want your old cluster + to be modified when the new cluster is started, make a copy of the + old cluster and upgrade that in link mode. To make a valid copy + of the old cluster, use rsync to create a dirty + copy of the old cluster while the server is running, then shut down + the old server and run rsync --checksum again to update the + copy with any changes to make it consistent. ( + + + + + See Also + + + + + + + + + diff --git a/doc/src/sgml/reference.sgml b/doc/src/sgml/reference.sgml index c1765ef1c5e..fb18d94ea09 100644 --- a/doc/src/sgml/reference.sgml +++ b/doc/src/sgml/reference.sgml @@ -263,6 +263,7 @@ &pgCtl; &pgResetxlog; &pgRewind; + &pgupgrade; &postgres; &postmaster; -- cgit v1.2.3