mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-11-27 07:21:09 +08:00
doc: use wording "restore" instead of "reload" of dumps
Reported-by: axel.kluener@gmail.com Discussion: https://postgr.es/m/164736074430.660.3645615289283943146@wrigleys.postgresql.org Backpatch-through: 11
This commit is contained in:
parent
624aa2a13b
commit
a4f09ef229
@ -557,7 +557,7 @@ CREATE TABLE products (
|
||||
tests, it cannot guarantee that the database will not reach a state
|
||||
in which the constraint condition is false (due to subsequent changes
|
||||
of the other row(s) involved). This would cause a database dump and
|
||||
reload to fail. The reload could fail even when the complete
|
||||
restore to fail. The restore could fail even when the complete
|
||||
database state is consistent with the constraint, due to rows not
|
||||
being loaded in an order that will satisfy the constraint. If
|
||||
possible, use <literal>UNIQUE</literal>, <literal>EXCLUDE</literal>,
|
||||
@ -569,10 +569,10 @@ CREATE TABLE products (
|
||||
If what you desire is a one-time check against other rows at row
|
||||
insertion, rather than a continuously-maintained consistency
|
||||
guarantee, a custom <link linkend="triggers">trigger</link> can be used
|
||||
to implement that. (This approach avoids the dump/reload problem because
|
||||
to implement that. (This approach avoids the dump/restore problem because
|
||||
<application>pg_dump</application> does not reinstall triggers until after
|
||||
reloading data, so that the check will not be enforced during a
|
||||
dump/reload.)
|
||||
restoring data, so that the check will not be enforced during a
|
||||
dump/restore.)
|
||||
</para>
|
||||
</note>
|
||||
|
||||
@ -594,7 +594,7 @@ CREATE TABLE products (
|
||||
function. <productname>PostgreSQL</productname> does not disallow
|
||||
that, but it will not notice if there are rows in the table that now
|
||||
violate the <literal>CHECK</literal> constraint. That would cause a
|
||||
subsequent database dump and reload to fail.
|
||||
subsequent database dump and restore to fail.
|
||||
The recommended way to handle such a change is to drop the constraint
|
||||
(using <command>ALTER TABLE</command>), adjust the function definition,
|
||||
and re-add the constraint, thereby rechecking it against all table rows.
|
||||
|
@ -982,7 +982,7 @@ SET LOCAL search_path TO @extschema@, pg_temp;
|
||||
<application>pg_dump</application>. But that behavior is undesirable for a
|
||||
configuration table; any data changes made by the user need to be
|
||||
included in dumps, or the extension will behave differently after a dump
|
||||
and reload.
|
||||
and restore.
|
||||
</para>
|
||||
|
||||
<indexterm>
|
||||
|
@ -1785,7 +1785,7 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
|
||||
|
||||
<para>
|
||||
Dump scripts generated by <application>pg_dump</application> automatically apply
|
||||
several, but not all, of the above guidelines. To reload a
|
||||
several, but not all, of the above guidelines. To restore a
|
||||
<application>pg_dump</application> dump as quickly as possible, you need to
|
||||
do a few extra things manually. (Note that these points apply while
|
||||
<emphasis>restoring</emphasis> a dump, not while <emphasis>creating</emphasis> it.
|
||||
|
@ -156,7 +156,7 @@
|
||||
attached to a function when <varname>check_function_bodies</varname> is on.
|
||||
Therefore, checks whose results might be affected by GUC parameters
|
||||
definitely should be skipped when <varname>check_function_bodies</varname> is
|
||||
off, to avoid false failures when reloading a dump.
|
||||
off, to avoid false failures when restoring a dump.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -411,7 +411,7 @@ ALTER TYPE <replaceable class="parameter">name</replaceable> SET ( <replaceable
|
||||
around</quote> since the original creation of the enum type). The slowdown is
|
||||
usually insignificant; but if it matters, optimal performance can be
|
||||
regained by dropping and recreating the enum type, or by dumping and
|
||||
reloading the database.
|
||||
restoring the database.
|
||||
</para>
|
||||
</refsect1>
|
||||
|
||||
|
@ -234,7 +234,7 @@ INSERT INTO tab (domcol) VALUES ((SELECT domcol FROM tab WHERE false));
|
||||
function. <productname>PostgreSQL</productname> does not disallow that,
|
||||
but it will not notice if there are stored values of the domain type that
|
||||
now violate the <literal>CHECK</literal> constraint. That would cause a
|
||||
subsequent database dump and reload to fail. The recommended way to
|
||||
subsequent database dump and restore to fail. The recommended way to
|
||||
handle such a change is to drop the constraint (using <command>ALTER
|
||||
DOMAIN</command>), adjust the function definition, and re-add the
|
||||
constraint, thereby rechecking it against stored data.
|
||||
|
@ -684,7 +684,7 @@ PostgreSQL documentation
|
||||
...</literal>). This will make restoration very slow; it is mainly
|
||||
useful for making dumps that can be loaded into
|
||||
non-<productname>PostgreSQL</productname> databases.
|
||||
Any error during reloading will cause only rows that are part of the
|
||||
Any error during restoring will cause only rows that are part of the
|
||||
problematic <command>INSERT</command> to be lost, rather than the
|
||||
entire table contents.
|
||||
</para>
|
||||
@ -708,9 +708,9 @@ PostgreSQL documentation
|
||||
This option is relevant only when creating a data-only dump.
|
||||
It instructs <application>pg_dump</application> to include commands
|
||||
to temporarily disable triggers on the target tables while
|
||||
the data is reloaded. Use this if you have referential
|
||||
the data is restored. Use this if you have referential
|
||||
integrity checks or other triggers on the tables that you
|
||||
do not want to invoke during data reload.
|
||||
do not want to invoke during data restore.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -828,7 +828,7 @@ PostgreSQL documentation
|
||||
than <command>COPY</command>). This will make restoration very slow;
|
||||
it is mainly useful for making dumps that can be loaded into
|
||||
non-<productname>PostgreSQL</productname> databases.
|
||||
Any error during reloading will cause only rows that are part of the
|
||||
Any error during restoring will cause only rows that are part of the
|
||||
problematic <command>INSERT</command> to be lost, rather than the
|
||||
entire table contents. Note that the restore might fail altogether if
|
||||
you have rearranged column order. The
|
||||
@ -847,7 +847,7 @@ PostgreSQL documentation
|
||||
target the root of the partitioning hierarchy that contains it, rather
|
||||
than the partition itself. This causes the appropriate partition to
|
||||
be re-determined for each row when the data is loaded. This may be
|
||||
useful when reloading data on a server where rows do not always fall
|
||||
useful when restoring data on a server where rows do not always fall
|
||||
into the same partitions as they did on the original server. That
|
||||
could happen, for example, if the partitioning column is of type text
|
||||
and the two systems have different definitions of the collation used
|
||||
@ -859,7 +859,7 @@ PostgreSQL documentation
|
||||
with this option, because <application>pg_restore</application> will
|
||||
not know exactly which partition(s) a given archive data item will
|
||||
load data into. This could result in inefficiency due to lock
|
||||
conflicts between parallel jobs, or perhaps even reload failures due
|
||||
conflicts between parallel jobs, or perhaps even restore failures due
|
||||
to foreign key constraints being set up before all the relevant data
|
||||
is loaded.
|
||||
</para>
|
||||
@ -1028,7 +1028,7 @@ PostgreSQL documentation
|
||||
Dump data as <command>INSERT</command> commands (rather than
|
||||
<command>COPY</command>). Controls the maximum number of rows per
|
||||
<command>INSERT</command> command. The value specified must be a
|
||||
number greater than zero. Any error during reloading will cause only
|
||||
number greater than zero. Any error during restoring will cause only
|
||||
rows that are part of the problematic <command>INSERT</command> to be
|
||||
lost, rather than the entire table contents.
|
||||
</para>
|
||||
|
@ -276,9 +276,9 @@ PostgreSQL documentation
|
||||
This option is relevant only when creating a data-only dump.
|
||||
It instructs <application>pg_dumpall</application> to include commands
|
||||
to temporarily disable triggers on the target tables while
|
||||
the data is reloaded. Use this if you have referential
|
||||
the data is restored. Use this if you have referential
|
||||
integrity checks or other triggers on the tables that you
|
||||
do not want to invoke during data reload.
|
||||
do not want to invoke during data restore.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -355,7 +355,7 @@ PostgreSQL documentation
|
||||
target the root of the partitioning hierarchy that contains it, rather
|
||||
than the partition itself. This causes the appropriate partition to
|
||||
be re-determined for each row when the data is loaded. This may be
|
||||
useful when reloading data on a server where rows do not always fall
|
||||
useful when restoring data on a server where rows do not always fall
|
||||
into the same partitions as they did on the original server. That
|
||||
could happen, for example, if the partitioning column is of type text
|
||||
and the two systems have different definitions of the collation used
|
||||
@ -530,7 +530,7 @@ PostgreSQL documentation
|
||||
Dump data as <command>INSERT</command> commands (rather than
|
||||
<command>COPY</command>). Controls the maximum number of rows per
|
||||
<command>INSERT</command> command. The value specified must be a
|
||||
number greater than zero. Any error during reloading will cause only
|
||||
number greater than zero. Any error during restoring will cause only
|
||||
rows that are part of the problematic <command>INSERT</command> to be
|
||||
lost, rather than the entire table contents.
|
||||
</para>
|
||||
@ -799,7 +799,7 @@ PostgreSQL documentation
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To reload database(s) from this file, you can use:
|
||||
To restore database(s) from this file, you can use:
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>psql -f db.out postgres</userinput>
|
||||
</screen>
|
||||
|
@ -55,7 +55,7 @@ PostgreSQL documentation
|
||||
After running this command, it should be possible to start the server,
|
||||
but bear in mind that the database might contain inconsistent data due to
|
||||
partially-committed transactions. You should immediately dump your data,
|
||||
run <command>initdb</command>, and reload. After reload, check for
|
||||
run <command>initdb</command>, and restore. After restore, check for
|
||||
inconsistencies and repair as needed.
|
||||
</para>
|
||||
|
||||
@ -78,7 +78,7 @@ PostgreSQL documentation
|
||||
discussed below. If you are not able to determine correct values for all
|
||||
these fields, <option>-f</option> can still be used, but
|
||||
the recovered database must be treated with even more suspicion than
|
||||
usual: an immediate dump and reload is imperative. <emphasis>Do not</emphasis>
|
||||
usual: an immediate dump and restore is imperative. <emphasis>Do not</emphasis>
|
||||
execute any data-modifying operations in the database before you dump,
|
||||
as any such action is likely to make the corruption worse.
|
||||
</para>
|
||||
|
@ -538,9 +538,9 @@ PostgreSQL documentation
|
||||
This option is relevant only when performing a data-only restore.
|
||||
It instructs <application>pg_restore</application> to execute commands
|
||||
to temporarily disable triggers on the target tables while
|
||||
the data is reloaded. Use this if you have referential
|
||||
the data is restored. Use this if you have referential
|
||||
integrity checks or other triggers on the tables that you
|
||||
do not want to invoke during data reload.
|
||||
do not want to invoke during data restore.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -969,7 +969,7 @@ CREATE DATABASE foo WITH TEMPLATE template0;
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To reload the dump into a new database called <literal>newdb</literal>:
|
||||
To restore the dump into a new database called <literal>newdb</literal>:
|
||||
|
||||
<screen>
|
||||
<prompt>$</prompt> <userinput>createdb -T template0 newdb</userinput>
|
||||
|
@ -39,7 +39,7 @@ PostgreSQL documentation
|
||||
<para>
|
||||
<application>pg_upgrade</application> (formerly called <application>pg_migrator</application>) allows data
|
||||
stored in <productname>PostgreSQL</productname> data files to be upgraded to a later <productname>PostgreSQL</productname>
|
||||
major version without the data dump/reload typically required for
|
||||
major version without the data dump/restore typically required for
|
||||
major version upgrades, e.g., from 9.5.8 to 9.6.4 or from 10.7 to 11.2.
|
||||
It is not required for minor version upgrades, e.g., from 9.6.2 to 9.6.3
|
||||
or from 10.1 to 10.2.
|
||||
@ -420,7 +420,7 @@ NET STOP postgresql-&majorversion;
|
||||
|
||||
<para>
|
||||
The <option>--jobs</option> option allows multiple CPU cores to be used
|
||||
for copying/linking of files and to dump and reload database schemas
|
||||
for copying/linking of files and to dump and restore database schemas
|
||||
in parallel; a good place to start is the maximum of the number of
|
||||
CPU cores and tablespaces. This option can dramatically reduce the
|
||||
time to upgrade a multi-database server running on a multiprocessor
|
||||
|
@ -1650,7 +1650,7 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
|
||||
For <emphasis>major</emphasis> releases of <productname>PostgreSQL</productname>, 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
|
||||
is to dump and restore the database, though this can be slow. A
|
||||
faster method is <xref linkend="pgupgrade"/>. Replication methods are
|
||||
also available, as discussed below.
|
||||
(If you are using a pre-packaged version
|
||||
@ -1736,7 +1736,7 @@ $ <userinput>kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`</userinput
|
||||
|
||||
<para>
|
||||
One upgrade method is to dump data from one major version of
|
||||
<productname>PostgreSQL</productname> and reload it in another — to do
|
||||
<productname>PostgreSQL</productname> and restore it in another — to do
|
||||
this, you must use a <emphasis>logical</emphasis> backup tool like
|
||||
<application>pg_dumpall</application>; file system
|
||||
level backup methods will not work. (There are checks in place that prevent
|
||||
|
@ -1974,7 +1974,7 @@ CREATE TRIGGER tsvectorupdate BEFORE INSERT OR UPDATE
|
||||
explicitly when creating <type>tsvector</type> values inside triggers,
|
||||
so that the column's contents will not be affected by changes to
|
||||
<varname>default_text_search_config</varname>. Failure to do this is likely to
|
||||
lead to problems such as search results changing after a dump and reload.
|
||||
lead to problems such as search results changing after a dump and restore.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
Loading…
Reference in New Issue
Block a user