On Wed, Mar 16, 2022 at 09:28:04AM +0100, Laurenz Albe wrote:
> On Tue, 2022-03-15 at 16:12 +0000, PG Doc comments form wrote:
> > Page: https://www.postgresql.org/docs/14/backup-dump.html
> >
> > As far as I can see, the terms "Reload" and "Restore" are used
> > interchangeably.
> > To make the page as easy digestable for the reader as possible, it´s
> > advisable to stick to exactly one term.
>
> That makes sense, particularly since "reload" typically means something
> else in PostgreSQL. I think "restore" is better.
>
> Do you feel like preparing a patch?
I have created the attached patch. The only place I left "reload" was
when it was used in pg_dump in "To reload an archive file" and similar
cases. In those cases, restoring a script or file might be
misinterpreted.
--
Bruce Momjian <br...@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index b01e3ad544..3717d13fff 100644
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -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.
diff --git a/doc/src/sgml/extend.sgml b/doc/src/sgml/extend.sgml
index b3857015b1..bf475e7aa0 100644
--- a/doc/src/sgml/extend.sgml
+++ b/doc/src/sgml/extend.sgml
@@ -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>
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
index 8fd8e25c51..c3ee47b3d6 100644
--- a/doc/src/sgml/perform.sgml
+++ b/doc/src/sgml/perform.sgml
@@ -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.
diff --git a/doc/src/sgml/plhandler.sgml b/doc/src/sgml/plhandler.sgml
index 40ee59de9f..980c95ecf3 100644
--- a/doc/src/sgml/plhandler.sgml
+++ b/doc/src/sgml/plhandler.sgml
@@ -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>
diff --git a/doc/src/sgml/ref/alter_type.sgml b/doc/src/sgml/ref/alter_type.sgml
index 21887e88a0..146065144f 100644
--- a/doc/src/sgml/ref/alter_type.sgml
+++ b/doc/src/sgml/ref/alter_type.sgml
@@ -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>
diff --git a/doc/src/sgml/ref/create_domain.sgml b/doc/src/sgml/ref/create_domain.sgml
index e4b856d630..82a0b87492 100644
--- a/doc/src/sgml/ref/create_domain.sgml
+++ b/doc/src/sgml/ref/create_domain.sgml
@@ -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.
diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml
index 5efb442b44..c08276bc0a 100644
--- a/doc/src/sgml/ref/pg_dump.sgml
+++ b/doc/src/sgml/ref/pg_dump.sgml
@@ -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>
diff --git a/doc/src/sgml/ref/pg_dumpall.sgml b/doc/src/sgml/ref/pg_dumpall.sgml
index 8a081f0080..5d54074e01 100644
--- a/doc/src/sgml/ref/pg_dumpall.sgml
+++ b/doc/src/sgml/ref/pg_dumpall.sgml
@@ -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>
diff --git a/doc/src/sgml/ref/pg_resetwal.sgml b/doc/src/sgml/ref/pg_resetwal.sgml
index 3e4882cdc6..fd539f5604 100644
--- a/doc/src/sgml/ref/pg_resetwal.sgml
+++ b/doc/src/sgml/ref/pg_resetwal.sgml
@@ -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>
diff --git a/doc/src/sgml/ref/pg_restore.sgml b/doc/src/sgml/ref/pg_restore.sgml
index 526986eadb..47bd7dbda0 100644
--- a/doc/src/sgml/ref/pg_restore.sgml
+++ b/doc/src/sgml/ref/pg_restore.sgml
@@ -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>
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
index d065227656..26459f7e91 100644
--- a/doc/src/sgml/ref/pgupgrade.sgml
+++ b/doc/src/sgml/ref/pgupgrade.sgml
@@ -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
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 92a1ea87d8..963b18ed85 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -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
diff --git a/doc/src/sgml/textsearch.sgml b/doc/src/sgml/textsearch.sgml
index 2cbf7e7d42..c51b0e4d77 100644
--- a/doc/src/sgml/textsearch.sgml
+++ b/doc/src/sgml/textsearch.sgml
@@ -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>
