database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-12-22 17:42:17 +03:00
Code Activity

doc: use wording "restore" instead of "reload" of dumps

Browse Source 
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:
Bruce Momjian
2022-07-21 14:55:23 -04:00
parent 624aa2a13b
commit a4f09ef229
13 changed files with 32 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/src/sgml/ref/alter_type.sgml
View File

@@ -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>

2
doc/src/sgml/ref/create_domain.sgml
View File

@@ -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.

14
doc/src/sgml/ref/pg_dump.sgml
View File

@@ -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>

10
doc/src/sgml/ref/pg_dumpall.sgml
View File

@@ -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>

4
doc/src/sgml/ref/pg_resetwal.sgml
View File

@@ -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>

6
doc/src/sgml/ref/pg_restore.sgml
View File

@@ -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>

4
doc/src/sgml/ref/pgupgrade.sgml
View File

@@ -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