From bf1c866597a0e59a30b13a66f3ae505655b61853 Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Mon, 25 Aug 2014 15:34:51 -0400
Subject: [PATCH] upgrade docs: highlight pg_upgrade, warn about globals
preservation
Also, remove OID preservation mention, mention non-text dump formats
Backpatch through 9.4
---
doc/src/sgml/backup.sgml | 27 ++++++++++++----------
doc/src/sgml/runtime.sgml | 47 ++++++++++++++++++++++++---------------
2 files changed, 44 insertions(+), 30 deletions(-)
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 06f064e1a6f..07ca0dc62d6 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -28,7 +28,7 @@
<title><acronym>SQL</> Dump</title>
<para>
- The idea behind this dump method is to generate a text file with SQL
+ 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.
<productname>PostgreSQL</> provides the utility program
@@ -39,6 +39,9 @@ pg_dump <replaceable class="parameter">dbname</replaceable> > <replaceable cl
</synopsis>
As you see, <application>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, <application>pg_dump</>
+ can create files in other formats that allow for parallism and more
+ fine-grained control of object restoration.
</para>
<para>
@@ -98,20 +101,11 @@ pg_dump <replaceable class="parameter">dbname</replaceable> > <replaceable cl
exclusive lock, such as most forms of <command>ALTER TABLE</command>.)
</para>
- <important>
- <para>
- If your database schema relies on OIDs (for instance, as foreign
- keys) you must instruct <application>pg_dump</> to dump the OIDs
- as well. To do this, use the <option>-o</option> command-line
- option.
- </para>
- </important>
-
<sect2 id="backup-dump-restore">
<title>Restoring the Dump</title>
<para>
- The text files created by <application>pg_dump</> are intended to
+ Text files created by <application>pg_dump</> are intended to
be read in by the <application>psql</application> program. The
general command form to restore a dump is
<synopsis>
@@ -127,6 +121,8 @@ psql <replaceable class="parameter">dbname</replaceable> < <replaceable class
supports options similar to <application>pg_dump</> for specifying
the database server to connect to and the user name to use. See
the <xref linkend="app-psql"> reference page for more information.
+ Non-text file dumps are restored using the <xref
+ linkend="app-pgrestore"> utility.
</para>
<para>
@@ -225,7 +221,14 @@ psql -f <replaceable class="parameter">infile</replaceable> postgres
roles, tablespaces, and empty databases, then invoking
<application>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.
+ different databases are not sychronized.
+ </para>
+
+ <para>
+ Cluster-wide data can be dumped alone using the
+ <application>pg_dumpall</> <option>--globals-only</> option.
+ This is necessary to fully backup the cluster if running the
+ <application>pg_dump</> command on individual databases.
</para>
</sect2>
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 1d91d92fe36..f3374857363 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1517,8 +1517,9 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
For <emphasis>major</> releases of <productname>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.
+ is to dump and reload the database, though this can be slow. A
+ faster method is <xref linkend="pgupgrade">. Replication methods are
+ also available, as discussed below.
</para>
<para>
@@ -1593,12 +1594,14 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
</variablelist>
- <sect2 id="upgrade-methods-pgdump">
- <title>Upgrading Data via <application>pg_dump</></title>
+ <sect2 id="upgrading-via-pgdumpall">
+ <title>Upgrading Data via <application>pg_dumpall</></title>
<para>
- To dump data from one major version of <productname>PostgreSQL</> and
- reload it in another, you must use <application>pg_dump</>; file system
+ One upgrade method is to dump data from one major version of
+ <productname>PostgreSQL</> and reload it in another — to do
+ this, you must use a <emphasis>logical</> backup tool like
+ <application>pg_dumpall</>; file system
level backup methods will not work. (There are checks in place that prevent
you from using a data directory with an incompatible version of
<productname>PostgreSQL</productname>, so no great harm can be done by
@@ -1607,7 +1610,8 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
<para>
It is recommended that you use the <application>pg_dump</> and
- <application>pg_dumpall</> programs from the newer version of
+ <application>pg_dumpall</> programs from the <emphasis>newer</>
+ version of
<productname>PostgreSQL</>, to take advantage of enhancements
that might have been made in these programs. Current releases of the
dump programs can read data from any server version back to 7.0.
@@ -1642,14 +1646,12 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
<screen>
<userinput>pg_dumpall > <replaceable>outputfile</></userinput>
</screen>
- If you need to preserve OIDs (such as when using them as
- foreign keys), then use the <option>-o</option> option when running
- <application>pg_dumpall</>.
</para>
<para>
To make the backup, you can use the <application>pg_dumpall</application>
- command from the version you are currently running. For best
+ command from the version you are currently running; see <xref
+ linkend="backup-dump-all"> for more details. For best
results, however, try to use the <application>pg_dumpall</application>
command from <productname>PostgreSQL</productname> &version;,
since this version contains bug fixes and improvements over older
@@ -1683,7 +1685,8 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
<step>
<para>
If restoring from backup, rename or delete the old installation
- directory. It is a good idea to rename the directory, rather than
+ 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:
@@ -1755,16 +1758,24 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433
</sect2>
- <sect2 id="upgrading-methods-other">
- <title>Non-Dump Upgrade Methods</title>
+ <sect2 id="upgrading-via-pg-upgrade">
+ <title>Upgrading Data via <application>pg_upgrade</></title>
<para>
- The <link linkend="pgupgrade">pg_upgrade</link> module allows an
- installation to be migrated in-place from one major
- <productname>PostgreSQL</> version to the next. Upgrades can be
- performed in minutes.
+ The <xref linkend="pgupgrade"> module allows an installation to
+ be migrated in-place from one major <productname>PostgreSQL</>
+ version to another. Upgrades can be performed in minutes,
+ particularly with <option>--link</> mode. It requires steps similar to
+ <application>pg_dumpall</> above, e.g. starting/stopping the server,
+ running <application>initdb</>. The <application>pg_upgrade</> <link
+ linkend="pgupgrade">documentation</> outlines the necessary steps.
</para>
+ </sect2>
+
+ <sect2 id="upgrading-via-replication">
+ <title>Upgrading Data via Replication</title>
+
<para>
It is also possible to use certain replication methods, such as
<productname>Slony</>, to create a standby server with the updated version of
--
GitLab