diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml new file mode 100644 index 06f064e..07ca0dc *** a/doc/src/sgml/backup.sgml --- b/doc/src/sgml/backup.sgml *************** *** 28,34 **** <acronym>SQL</> Dump ! The idea behind this dump method is to generate a text file with SQL commands that, when fed back to the server, will recreate the database in the same state as it was at the time of the dump. PostgreSQL provides the utility program --- 28,34 ---- <acronym>SQL</> Dump ! The idea behind this dump method is to generate a file with SQL commands that, when fed back to the server, will recreate the database in the same state as it was at the time of the dump. PostgreSQL provides the utility program *************** pg_dump d *** 39,44 **** --- 39,47 ---- As you see, pg_dump writes its result to the standard output. We will see below how this can be useful. + While the above command creates a text file, pg_dump + can create files in other formats that allow for parallism and more + fine-grained control of object restoration. *************** pg_dump d *** 98,117 **** exclusive lock, such as most forms of ALTER TABLE.) - - - If your database schema relies on OIDs (for instance, as foreign - keys) you must instruct pg_dump to dump the OIDs - as well. To do this, use the command-line - option. - - - Restoring the Dump ! The text files created by pg_dump are intended to be read in by the psql program. The general command form to restore a dump is --- 101,111 ---- exclusive lock, such as most forms of ALTER TABLE.) Restoring the Dump ! Text files created by pg_dump are intended to be read in by the psql program. The general command form to restore a dump is *************** psql dbna *** 127,132 **** --- 121,128 ---- supports options similar to pg_dump for specifying the database server to connect to and the user name to use. See the reference page for more information. + Non-text file dumps are restored using the utility. *************** psql -f i *** 225,231 **** roles, tablespaces, and empty databases, then invoking pg_dump for each database. This means that while each database will be internally consistent, the snapshots of ! different databases might not be exactly in-sync. --- 221,234 ---- roles, tablespaces, and empty databases, then invoking pg_dump for each database. This means that while each database will be internally consistent, the snapshots of ! different databases are not sychronized. ! ! ! ! Cluster-wide data can be dumped alone using the ! pg_dumpall diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml new file mode 100644 index 1d91d92..00cb7cb *** a/doc/src/sgml/runtime.sgml --- b/doc/src/sgml/runtime.sgml *************** $ kill -INT `head -1 /usr/loc *** 1517,1524 **** For major releases of PostgreSQL, the internal data storage format is subject to change, thus complicating upgrades. The traditional method for moving data to a new major version ! is to dump and reload the database. Other methods are available, ! as discussed below. --- 1517,1525 ---- For major releases of PostgreSQL, the internal data storage format is subject to change, thus complicating upgrades. The traditional method for moving data to a new major version ! is to dump and reload the database, though this can be slow. A ! faster method is . Replication methods are ! also available, as discussed below. *************** $ kill -INT `head -1 /usr/loc *** 1593,1600 **** ! ! Upgrading Data via <application>pg_dump</> To dump data from one major version of PostgreSQL and --- 1594,1601 ---- ! ! Upgrading Data via <application>pg_dumpall</> To dump data from one major version of PostgreSQL and *************** $ kill -INT `head -1 /usr/loc *** 1642,1655 **** pg_dumpall > outputfile - If you need to preserve OIDs (such as when using them as - foreign keys), then use the option when running - pg_dumpall. To make the backup, you can use the pg_dumpall ! command from the version you are currently running. For best results, however, try to use the pg_dumpall command from PostgreSQL &version;, since this version contains bug fixes and improvements over older --- 1643,1654 ---- pg_dumpall > outputfile To make the backup, you can use the pg_dumpall ! command from the version you are currently running; see for more details. For best results, however, try to use the pg_dumpall command from PostgreSQL &version;, since this version contains bug fixes and improvements over older *************** $ kill -INT `head -1 /usr/loc *** 1683,1689 **** If restoring from backup, rename or delete the old installation ! directory. It is a good idea to rename the directory, rather than delete it, in case you have trouble and need to revert to it. Keep in mind the directory might consume significant disk space. To rename the directory, use a command like this: --- 1682,1689 ---- If restoring from backup, rename or delete the old installation ! directory if it is not version-specific. It is a good idea to ! rename the directory, rather than delete it, in case you have trouble and need to revert to it. Keep in mind the directory might consume significant disk space. To rename the directory, use a command like this: *************** pg_dumpall -p 5432 | psql -d postgres -p *** 1755,1770 **** ! ! Non-Dump Upgrade Methods ! The pg_upgrade module allows an ! installation to be migrated in-place from one major ! PostgreSQL version to the next. Upgrades can be ! performed in minutes. It is also possible to use certain replication methods, such as Slony, to create a standby server with the updated version of --- 1755,1778 ---- ! ! Upgrading Data via <application>pg_upgrade</> ! The module allows an installation to ! be migrated in-place from one major PostgreSQL ! version to another. Upgrades can be performed in minutes. ! It requires steps similar to pg_dumpall above, e.g. ! starting/stopping the server, running initdb. The ! pg_upgrade documentation ! outlines the necessary steps. + + + + Upgrading Data via Replication + It is also possible to use certain replication methods, such as Slony, to create a standby server with the updated version of