public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v7 07/10] doc: backup manifests
30+ messages / 4 participants
[nested] [flat]
* [PATCH v7 07/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..44e7b2444b 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -368,7 +368,7 @@ PostgreSQL documentation
</para>
<para>
The following command-line options control the generation of the
- backup and the running of the program:
+ backup and the invocation of the program:
<variablelist>
<varlistentry>
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..4f72a1f126 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,8 +121,8 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
-
+ <application>pg_verifybackup</application> accepts the following
+ command-line arguments:
<variablelist>
<varlistentry>
<term><option>-e</option></term>
--
2.17.0
--AsxXAMtlQ5JHofzM
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="v7-0008-doc-pgbench-cmdline.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v8 07/14] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..44e7b2444b 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -368,7 +368,7 @@ PostgreSQL documentation
</para>
<para>
The following command-line options control the generation of the
- backup and the running of the program:
+ backup and the invocation of the program:
<variablelist>
<varlistentry>
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..4f72a1f126 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,8 +121,8 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
-
+ <application>pg_verifybackup</application> accepts the following
+ command-line arguments:
<variablelist>
<varlistentry>
<term><option>-e</option></term>
--
2.17.0
--0eh6TmSyL6TZE2Uz
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="v8-0008-doc-pgbench-cmdline.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v9 06/15] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index c3cb7b4255..f5e3318106 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2587,7 +2587,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2603,7 +2603,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..44e7b2444b 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -368,7 +368,7 @@ PostgreSQL documentation
</para>
<para>
The following command-line options control the generation of the
- backup and the running of the program:
+ backup and the invocation of the program:
<variablelist>
<varlistentry>
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
--
2.17.0
--L6iaP+gRLNZHKoI4
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="v9-0007-doc-pgbench-cmdline.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH v6 08/10] doc: backup manifests
@ 2020-04-03 21:17 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Justin Pryzby @ 2020-04-03 21:17 UTC (permalink / raw)
commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661
Author: Robert Haas <[email protected]>
Previously reported here:
https://www.postgresql.org/message-id/20200403212445.GB12283%40telsasoft.com
---
doc/src/sgml/protocol.sgml | 4 ++--
doc/src/sgml/ref/pg_basebackup.sgml | 4 ++--
doc/src/sgml/ref/pg_verifybackup.sgml | 6 +++---
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 8b00235a51..c402b97903 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -2586,7 +2586,7 @@ The commands accepted in replication mode are:
and sent along with the backup. The manifest is a list of every
file present in the backup with the exception of any WAL files that
may be included. It also stores the size, last modification time, and
- an optional checksum for each file.
+ optionally a checksum for each file.
A value of <literal>force-encode</literal> forces all filenames
to be hex-encoded; otherwise, this type of encoding is performed only
for files whose names are non-UTF8 octet sequences.
@@ -2602,7 +2602,7 @@ The commands accepted in replication mode are:
<term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></term>
<listitem>
<para>
- Specifies the algorithm that should be applied to each file included
+ Specifies the checksum algorithm that should be applied to each file included
in the backup manifest. Currently, the available
algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
<literal>SHA224</literal>, <literal>SHA256</literal>,
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml
index aa0b27c9f3..024adcb0b5 100644
--- a/doc/src/sgml/ref/pg_basebackup.sgml
+++ b/doc/src/sgml/ref/pg_basebackup.sgml
@@ -530,7 +530,7 @@ PostgreSQL documentation
not contain any checksums. Otherwise, it will contain a checksum
of each file in the backup using the specified algorithm. In addition,
the manifest will always contain a <literal>SHA256</literal>
- checksum of its own contents. The <literal>SHA</literal> algorithms
+ checksum of its own content. The <literal>SHA</literal> algorithms
are significantly more CPU-intensive than <literal>CRC32C</literal>,
so selecting one of them may increase the time required to complete
the backup.
@@ -540,7 +540,7 @@ PostgreSQL documentation
of each file for users who wish to verify that the backup has not been
tampered with, while the CRC32C algorithm provides a checksum that is
much faster to calculate; it is good at catching errors due to accidental
- changes but is not resistant to targeted modifications. Note that, to
+ changes but is not resistant to malicious modifications. Note that, to
be useful against an adversary who has access to the backup, the backup
manifest would need to be stored securely elsewhere or otherwise
verified not to have been modified since the backup was taken.
diff --git a/doc/src/sgml/ref/pg_verifybackup.sgml b/doc/src/sgml/ref/pg_verifybackup.sgml
index c160992e6d..b12e134a44 100644
--- a/doc/src/sgml/ref/pg_verifybackup.sgml
+++ b/doc/src/sgml/ref/pg_verifybackup.sgml
@@ -44,7 +44,7 @@ PostgreSQL documentation
every check which will be performed by a running server when attempting
to make use of the backup. Even if you use this tool, you should still
perform test restores and verify that the resulting databases work as
- expected and that they appear to contain the correct data. However,
+ expected and that they contain the correct data. However,
<application>pg_verifybackup</application> can detect many problems
that commonly occur due to storage problems or user error.
</para>
@@ -82,7 +82,7 @@ PostgreSQL documentation
for any files for which the computed checksum does not match the
checksum stored in the manifest. This step is not performed for any files
which produced errors in the previous step, since they are already known
- to have problems. Also, files which were ignored in the previous step are
+ to have problems. Files which were ignored in the previous step are
also ignored in this step.
</para>
@@ -121,7 +121,7 @@ PostgreSQL documentation
<title>Options</title>
<para>
- The following command-line options control the behavior.
+ The following command-line options control the behavior of this program.
<variablelist>
<varlistentry>
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0009-Say-it-more-naturally.patch"
^ permalink raw reply [nested|flat] 30+ messages in thread
* [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16
@ 2023-01-22 13:41 Joel Jacobson <[email protected]>
0 siblings, 1 reply; 30+ messages in thread
From: Joel Jacobson @ 2023-01-22 13:41 UTC (permalink / raw)
To: pgsql-hackers
Hi,
On platforms where we support 128bit integers, we could accelerate division
when the number of digits in the divisor is larger than 8 and less than or
equal to 16 digits, i.e. when the divisor that fits in a 64-bit integer but would
not fit in a 32-bit integer.
This patch adds div_var_int64(), which is similar to the existing div_var_int(),
but accepts a 64-bit divisor instead of a 32-bit divisor.
The new function is used within div_var() and div_var_fast().
To measure the effect, we need a volatile wrapper function for numeric_div(),
to avoid it being cached since it's immutable:
CREATE OR REPLACE FUNCTION numeric_div_volatile(numeric,numeric)
RETURNS numeric LANGUAGE internal AS 'numeric_div';
We can then use generate_series() to measure the execution time for lots of
executions. This does not account for the overhead of generate_series() and
count(), but that's okay since the overhead is the same in both measurements,
so the relative difference is still correct.
--
-- Division when the divisor is 8 digits should be unchanged:
--
EXPLAIN ANALYZE
SELECT count(numeric_div_volatile(
repeat('1',131071)::numeric,
repeat('3',8)::numeric
)) FROM generate_series(1,1e4);
-- Execution Time: 1633.722 ms (HEAD)
-- Execution Time: 1680.228 ms (div_var_int64.patch)
--
-- Division when the divisor is 9 digits should be faster:
--
EXPLAIN ANALYZE
SELECT count(numeric_div_volatile(
repeat('1',131071)::numeric,
repeat('3',9)::numeric
)) FROM generate_series(1,1e4);
-- Execution Time: 5444.755 ms (HEAD)
-- Execution Time: 1604.967 ms (div_var_int64.patch)
--
-- Division when the divisor is 16 digits should also be faster:
--
EXPLAIN ANALYZE
SELECT count(numeric_div_volatile(
repeat('1',131071)::numeric,
repeat('3',16)::numeric
)) FROM generate_series(1,1e4);
-- Execution Time: 6072.683 ms (HEAD)
-- Execution Time: 3215.686 ms (div_var_int64.patch)
--
-- Division when the divisor is 17 digits should be unchanged:
--
EXPLAIN ANALYZE
SELECT count(numeric_div_volatile(
repeat('1',131071)::numeric,
repeat('3',17)::numeric
)) FROM generate_series(1,1e4);
-- Execution Time: 6948.150 ms (HEAD)
-- Execution Time: 7010.544 ms (div_var_int64.patch)
--
-- Same tests as above, but with a single digit dividend,
-- and 1e7 executions instead of just 1e4.
--
--
-- Division when the divisor is 8 digits should be unchanged:
--
EXPLAIN ANALYZE
SELECT count(numeric_div_volatile(
1,
repeat('3',8)::numeric
)) FROM generate_series(1,1e7);
-- Execution Time: 1827.567 ms (HEAD)
-- Execution Time: 1828.029 ms (div_var_int64.patch)
--
-- Division when the divisor is 9 digits should be faster:
--
EXPLAIN ANALYZE
SELECT count(numeric_div_volatile(
1,
repeat('3',9)::numeric
)) FROM generate_series(1,1e7);
-- Execution Time: 2314.851 ms (HEAD)
-- Execution Time: 1886.170 ms (div_var_int64.patch)
--
-- Division when the divisor is 16 digits should also be faster:
--
EXPLAIN ANALYZE
SELECT count(numeric_div_volatile(
1,
repeat('3',16)::numeric
)) FROM generate_series(1,1e7);
-- Execution Time: 2244.009 ms (HEAD)
-- Execution Time: 1968.148 ms (div_var_int64.patch)
--
-- Division when the divisor is 17 digits should be unchanged:
--
EXPLAIN ANALYZE
SELECT count(numeric_div_volatile(
1,
repeat('3',17)::numeric
)) FROM generate_series(1,1e7);
-- Execution Time: 2334.896 ms (HEAD)
-- Execution Time: 2338.141 ms (div_var_int64.patch)
The graph below shows the effect on execution time for numeric_div(),
and also looks at numeric_mod() since it's a heavy user of numeric_div().
The graph was produced by generating 100 random numeric integer values
for each combination of number of dividend/divisor digits between 1 to 20.
In total, that's 20*20*100*2=80000 test values.
As expected, the ceiling for the fast short division is lifted from 8 to 16 divisor digits,
and speedups for modulus is noticed in the same region.
The graph was produced using results from pg-timeit [1] and R for the plotting.
[1] https://github.com/joelonsql/pg-timeit
/Joel
Attachments:
[image/png] image.png (117.8K, ../../[email protected]/3-image.png)
download | view image
[application/octet-stream] div_var_int64.patch (6.2K, ../../[email protected]/4-div_var_int64.patch)
download | inline diff:
diff --git a/src/backend/utils/adt/numeric.c b/src/backend/utils/adt/numeric.c
index a6409ecbee..30b0e339ff 100644
--- a/src/backend/utils/adt/numeric.c
+++ b/src/backend/utils/adt/numeric.c
@@ -554,6 +554,10 @@ static void div_var_fast(const NumericVar *var1, const NumericVar *var2,
NumericVar *result, int rscale, bool round);
static void div_var_int(const NumericVar *var, int ival, int ival_weight,
NumericVar *result, int rscale, bool round);
+#ifdef HAVE_INT128
+static void div_var_int64(const NumericVar *var, int64 ival, int ival_weight,
+ NumericVar *result, int rscale, bool round);
+#endif
static int select_div_scale(const NumericVar *var1, const NumericVar *var2);
static void mod_var(const NumericVar *var1, const NumericVar *var2,
NumericVar *result);
@@ -8484,7 +8488,32 @@ div_var(const NumericVar *var1, const NumericVar *var2, NumericVar *result,
/*
* If the divisor has just one or two digits, delegate to div_var_int(),
* which uses fast short division.
+ *
+ * On platforms with 128-bit integer support, and if the divisor has
+ * three or four digits, delegate to div_var_int64(),
+ * which also uses fast short division.
*/
+ #ifdef HAVE_INT128
+ if (var2ndigits <= 4)
+ {
+ int64 idivisor;
+ int idivisor_weight;
+
+ idivisor = var2->digits[0];
+ idivisor_weight = var2->weight;
+ for (i = 1; i < var2ndigits; i++)
+ {
+ idivisor *= NBASE;
+ idivisor += var2->digits[i];
+ idivisor_weight--;
+ }
+ if (var2->sign == NUMERIC_NEG)
+ idivisor = -idivisor;
+
+ div_var_int64(var1, idivisor, idivisor_weight, result, rscale, round);
+ return;
+ }
+ #else
if (var2ndigits <= 2)
{
int idivisor;
@@ -8503,6 +8532,7 @@ div_var(const NumericVar *var1, const NumericVar *var2, NumericVar *result,
div_var_int(var1, idivisor, idivisor_weight, result, rscale, round);
return;
}
+ #endif
/*
* Otherwise, perform full long division.
@@ -8774,7 +8804,32 @@ div_var_fast(const NumericVar *var1, const NumericVar *var2,
/*
* If the divisor has just one or two digits, delegate to div_var_int(),
* which uses fast short division.
+ *
+ * On platforms with 128-bit integer support, and if the divisor has
+ * three or four digits, delegate to div_var_int64(),
+ * which also uses fast short division.
*/
+ #ifdef HAVE_INT128
+ if (var2ndigits <= 4)
+ {
+ int64 idivisor;
+ int idivisor_weight;
+
+ idivisor = var2->digits[0];
+ idivisor_weight = var2->weight;
+ for (i = 1; i < var2ndigits; i++)
+ {
+ idivisor *= NBASE;
+ idivisor += var2->digits[i];
+ idivisor_weight--;
+ }
+ if (var2->sign == NUMERIC_NEG)
+ idivisor = -idivisor;
+
+ div_var_int64(var1, idivisor, idivisor_weight, result, rscale, round);
+ return;
+ }
+ #else
if (var2ndigits <= 2)
{
int idivisor;
@@ -8793,6 +8848,7 @@ div_var_fast(const NumericVar *var1, const NumericVar *var2,
div_var_int(var1, idivisor, idivisor_weight, result, rscale, round);
return;
}
+ #endif
/*
* Otherwise, perform full long division.
@@ -9182,6 +9238,118 @@ div_var_int(const NumericVar *var, int ival, int ival_weight,
}
+/*
+ * div_var_int64() -
+ *
+ * Divide a numeric variable by a 64-bit integer with the specified weight.
+ * The quotient var / (ival * NBASE^ival_weight) is stored in result.
+ */
+static void
+div_var_int64(const NumericVar *var, int64 ival, int ival_weight,
+ NumericVar *result, int rscale, bool round)
+{
+ NumericDigit *var_digits = var->digits;
+ int var_ndigits = var->ndigits;
+ int res_sign;
+ int res_weight;
+ int res_ndigits;
+ NumericDigit *res_buf;
+ NumericDigit *res_digits;
+ uint64 divisor;
+ int i;
+
+ /* Guard against division by zero */
+ if (ival == 0)
+ ereport(ERROR,
+ errcode(ERRCODE_DIVISION_BY_ZERO),
+ errmsg("division by zero"));
+
+ /* Result zero check */
+ if (var_ndigits == 0)
+ {
+ zero_var(result);
+ result->dscale = rscale;
+ return;
+ }
+
+ /*
+ * Determine the result sign, weight and number of digits to calculate.
+ * The weight figured here is correct if the emitted quotient has no
+ * leading zero digits; otherwise strip_var() will fix things up.
+ */
+ if (var->sign == NUMERIC_POS)
+ res_sign = ival > 0 ? NUMERIC_POS : NUMERIC_NEG;
+ else
+ res_sign = ival > 0 ? NUMERIC_NEG : NUMERIC_POS;
+ res_weight = var->weight - ival_weight;
+ /* The number of accurate result digits we need to produce: */
+ res_ndigits = res_weight + 1 + (rscale + DEC_DIGITS - 1) / DEC_DIGITS;
+ /* ... but always at least 1 */
+ res_ndigits = Max(res_ndigits, 1);
+ /* If rounding needed, figure one more digit to ensure correct result */
+ if (round)
+ res_ndigits++;
+
+ res_buf = digitbuf_alloc(res_ndigits + 1);
+ res_buf[0] = 0; /* spare digit for later rounding */
+ res_digits = res_buf + 1;
+
+ /*
+ * Now compute the quotient digits. This is the short division algorithm
+ * described in Knuth volume 2, section 4.3.1 exercise 16, except that we
+ * allow the divisor to exceed the internal base.
+ *
+ * In this algorithm, the carry from one digit to the next is at most
+ * divisor - 1. Therefore, while processing the next digit, carry may
+ * become as large as divisor * NBASE - 1, and so it requires a 128-bit
+ * integer if this exceeds ULONG_MAX.
+ */
+ divisor = i64abs(ival);
+
+ if (divisor <= ULONG_MAX / NBASE)
+ {
+ /* carry cannot overflow 64 bits */
+ uint64 carry = 0;
+
+ for (i = 0; i < res_ndigits; i++)
+ {
+ carry = carry * NBASE + (i < var_ndigits ? var_digits[i] : 0);
+ res_digits[i] = (NumericDigit) (carry / divisor);
+ carry = carry % divisor;
+ }
+ }
+ else
+ {
+ /* carry may exceed 64 bits */
+ uint128 carry = 0;
+
+ for (i = 0; i < res_ndigits; i++)
+ {
+ carry = carry * NBASE + (i < var_ndigits ? var_digits[i] : 0);
+ res_digits[i] = (NumericDigit) (carry / divisor);
+ carry = carry % divisor;
+ }
+ }
+
+ /* Store the quotient in result */
+ digitbuf_free(result->buf);
+ result->ndigits = res_ndigits;
+ result->buf = res_buf;
+ result->digits = res_digits;
+ result->weight = res_weight;
+ result->sign = res_sign;
+
+ /* Round or truncate to target rscale (and set result->dscale) */
+ if (round)
+ round_var(result, rscale);
+ else
+ trunc_var(result, rscale);
+
+ /* Strip leading/trailing zeroes */
+ strip_var(result);
+}
+
+
/*
* Default scale selection for division
*
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16
@ 2023-01-22 15:06 Dean Rasheed <[email protected]>
parent: Joel Jacobson <[email protected]>
0 siblings, 1 reply; 30+ messages in thread
From: Dean Rasheed @ 2023-01-22 15:06 UTC (permalink / raw)
To: Joel Jacobson <[email protected]>; +Cc: pgsql-hackers
On Sun, 22 Jan 2023 at 13:42, Joel Jacobson <[email protected]> wrote:
>
> Hi,
>
> On platforms where we support 128bit integers, we could accelerate division
> when the number of digits in the divisor is larger than 8 and less than or
> equal to 16 digits, i.e. when the divisor that fits in a 64-bit integer but would
> not fit in a 32-bit integer.
>
Seems like a reasonable idea, with some pretty decent gains.
Note, however, that for a divisor having fewer than 5 or 6 digits,
it's now significantly slower because it's forced to go through
div_var_int64() instead of div_var_int() for all small divisors. So
the var2ndigits <= 2 case needs to come first.
The implementation of div_var_int64() should be in an #ifdef HAVE_INT128 block.
In div_var_int64(), s/ULONG_MAX/PG_UINT64_MAX/
Regards,
Dean
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16
@ 2023-01-22 15:41 Joel Jacobson <[email protected]>
parent: Dean Rasheed <[email protected]>
0 siblings, 2 replies; 30+ messages in thread
From: Joel Jacobson @ 2023-01-22 15:41 UTC (permalink / raw)
To: Dean Rasheed <[email protected]>; +Cc: pgsql-hackers
On Sun, Jan 22, 2023, at 11:06, Dean Rasheed wrote:
> Seems like a reasonable idea, with some pretty decent gains.
>
> Note, however, that for a divisor having fewer than 5 or 6 digits,
> it's now significantly slower because it's forced to go through
> div_var_int64() instead of div_var_int() for all small divisors. So
> the var2ndigits <= 2 case needs to come first.
Can you give a measurable example of when the patch
the way it's written is significantly slower for a divisor having
fewer than 5 or 6 digits, on some platform?
I can't detect any difference at all at my MacBook Pro M1 Max for this example:
EXPLAIN ANALYZE SELECT count(numeric_div_volatile(1,3333)) FROM generate_series(1,1e8);
I did write the code like you suggest first, but changed it,
since I realised the extra "else if" needed could be eliminated,
and thought div_var_int64() wouldn't be slower than div_var_int() since
I thought 64-bit instructions in general are as fast as 32-bit instructions,
on 64-bit platforms.
I'm not suggesting your claim is incorrect, I'm just trying to understand
and verify it experimentally.
> The implementation of div_var_int64() should be in an #ifdef HAVE_INT128 block.
>
> In div_var_int64(), s/ULONG_MAX/PG_UINT64_MAX/
OK, thanks, I'll fix, but I'll await your feedback first on the above.
/Joel
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16
@ 2023-01-22 17:25 Dean Rasheed <[email protected]>
parent: Joel Jacobson <[email protected]>
1 sibling, 1 reply; 30+ messages in thread
From: Dean Rasheed @ 2023-01-22 17:25 UTC (permalink / raw)
To: Joel Jacobson <[email protected]>; +Cc: pgsql-hackers
On Sun, 22 Jan 2023 at 15:41, Joel Jacobson <[email protected]> wrote:
>
> On Sun, Jan 22, 2023, at 11:06, Dean Rasheed wrote:
> > Seems like a reasonable idea, with some pretty decent gains.
> >
> > Note, however, that for a divisor having fewer than 5 or 6 digits,
> > it's now significantly slower because it's forced to go through
> > div_var_int64() instead of div_var_int() for all small divisors. So
> > the var2ndigits <= 2 case needs to come first.
>
> Can you give a measurable example of when the patch
> the way it's written is significantly slower for a divisor having
> fewer than 5 or 6 digits, on some platform?
>
I just modified the previous test you posted:
\timing on
SELECT count(numeric_div_volatile(1e131071,123456)) FROM generate_series(1,1e4);
Time: 2048.060 ms (00:02.048) -- HEAD
Time: 2422.720 ms (00:02.423) -- With patch
> I did write the code like you suggest first, but changed it,
> since I realised the extra "else if" needed could be eliminated,
> and thought div_var_int64() wouldn't be slower than div_var_int() since
> I thought 64-bit instructions in general are as fast as 32-bit instructions,
> on 64-bit platforms.
>
Apparently it can make a difference. Probably something to do with
having less data to move around. I remember noticing that when I wrote
div_var_int(), which is why I split it into 2 branches in that way.
Regards,
Dean
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16
@ 2023-01-22 22:48 Joel Jacobson <[email protected]>
parent: Dean Rasheed <[email protected]>
0 siblings, 1 reply; 30+ messages in thread
From: Joel Jacobson @ 2023-01-22 22:48 UTC (permalink / raw)
To: Dean Rasheed <[email protected]>; +Cc: pgsql-hackers
On Sun, Jan 22, 2023, at 14:25, Dean Rasheed wrote:
> I just modified the previous test you posted:
>
> \timing on
> SELECT count(numeric_div_volatile(1e131071,123456)) FROM generate_series(1,1e4);
>
> Time: 2048.060 ms (00:02.048) -- HEAD
> Time: 2422.720 ms (00:02.423) -- With patch
>
...
>
> Apparently it can make a difference. Probably something to do with
> having less data to move around. I remember noticing that when I wrote
> div_var_int(), which is why I split it into 2 branches in that way.
Many thanks for feedback. Nice catch! New patch attached.
Interesting, I'm not able to reproduce this on my MacBook Pro M1 Max:
SELECT version;
PostgreSQL 16devel on aarch64-apple-darwin22.2.0, compiled by Apple clang version 14.0.0 (clang-1400.0.29.202), 64-bit
SELECT count(numeric_div_volatile(1e131071,123456)) FROM generate_series(1,1e 4);
Time: 1569.730 ms (00:01.570) - HEAD
Time: 1569.918 ms (00:01.570) -- div_var_int64.patch
Time: 1569.038 ms (00:01.569) -- div_var_int64-2.patch
Just curious, what platform are you on?
/Joel
Attachments:
[application/octet-stream] div_var_int64-2.patch (6.8K, ../../[email protected]/2-div_var_int64-2.patch)
download | inline diff:
From 30d718db26f442f558e2df9a7604b8bbdcd4ae94 Mon Sep 17 00:00:00 2001
From: Joel Jakobsson <[email protected]>
Date: Sun, 22 Jan 2023 12:57:30 -0400
Subject: [PATCH 1/5] Use 128-bit math to accelerate numeric division, when 8 <
divisor digits <= 16
This patch adds div_var_int64(), which is similar to the existing div_var_int(),
but accepts a 64-bit divisor instead of a 32-bit divisor.
The new function is used within div_var() and div_var_fast().
---
src/backend/utils/adt/numeric.c | 167 ++++++++++++++++++++++++++++++++
1 file changed, 167 insertions(+)
diff --git a/src/backend/utils/adt/numeric.c b/src/backend/utils/adt/numeric.c
index a6409ecbee..e48493ac4a 100644
--- a/src/backend/utils/adt/numeric.c
+++ b/src/backend/utils/adt/numeric.c
@@ -554,6 +554,10 @@ static void div_var_fast(const NumericVar *var1, const NumericVar *var2,
NumericVar *result, int rscale, bool round);
static void div_var_int(const NumericVar *var, int ival, int ival_weight,
NumericVar *result, int rscale, bool round);
+#ifdef HAVE_INT128
+static void div_var_int64(const NumericVar *var, int64 ival, int ival_weight,
+ NumericVar *result, int rscale, bool round);
+#endif
static int select_div_scale(const NumericVar *var1, const NumericVar *var2);
static void mod_var(const NumericVar *var1, const NumericVar *var2,
NumericVar *result);
@@ -8484,6 +8488,10 @@ div_var(const NumericVar *var1, const NumericVar *var2, NumericVar *result,
/*
* If the divisor has just one or two digits, delegate to div_var_int(),
* which uses fast short division.
+ *
+ * On platforms with 128-bit integer support, and if the divisor has
+ * three or four digits, delegate to div_var_int64(),
+ * which also uses fast short division.
*/
if (var2ndigits <= 2)
{
@@ -8503,6 +8511,27 @@ div_var(const NumericVar *var1, const NumericVar *var2, NumericVar *result,
div_var_int(var1, idivisor, idivisor_weight, result, rscale, round);
return;
}
+ #ifdef HAVE_INT128
+ else if (var2ndigits <= 4)
+ {
+ int64 idivisor;
+ int idivisor_weight;
+
+ idivisor = var2->digits[0];
+ idivisor_weight = var2->weight;
+ for (i = 1; i < var2ndigits; i++)
+ {
+ idivisor *= NBASE;
+ idivisor += var2->digits[i];
+ idivisor_weight--;
+ }
+ if (var2->sign == NUMERIC_NEG)
+ idivisor = -idivisor;
+
+ div_var_int64(var1, idivisor, idivisor_weight, result, rscale, round);
+ return;
+ }
+ #endif
/*
* Otherwise, perform full long division.
@@ -8774,6 +8803,10 @@ div_var_fast(const NumericVar *var1, const NumericVar *var2,
/*
* If the divisor has just one or two digits, delegate to div_var_int(),
* which uses fast short division.
+ *
+ * On platforms with 128-bit integer support, and if the divisor has
+ * three or four digits, delegate to div_var_int64(),
+ * which also uses fast short division.
*/
if (var2ndigits <= 2)
{
@@ -8793,6 +8826,27 @@ div_var_fast(const NumericVar *var1, const NumericVar *var2,
div_var_int(var1, idivisor, idivisor_weight, result, rscale, round);
return;
}
+ #ifdef HAVE_INT128
+ else if (var2ndigits <= 4)
+ {
+ int64 idivisor;
+ int idivisor_weight;
+
+ idivisor = var2->digits[0];
+ idivisor_weight = var2->weight;
+ for (i = 1; i < var2ndigits; i++)
+ {
+ idivisor *= NBASE;
+ idivisor += var2->digits[i];
+ idivisor_weight--;
+ }
+ if (var2->sign == NUMERIC_NEG)
+ idivisor = -idivisor;
+
+ div_var_int64(var1, idivisor, idivisor_weight, result, rscale, round);
+ return;
+ }
+ #endif
/*
* Otherwise, perform full long division.
@@ -9182,6 +9236,119 @@ div_var_int(const NumericVar *var, int ival, int ival_weight,
}
+#ifdef HAVE_INT128
+/*
+ * div_var_int64() -
+ *
+ * Divide a numeric variable by a 64-bit integer with the specified weight.
+ * The quotient var / (ival * NBASE^ival_weight) is stored in result.
+ */
+static void
+div_var_int64(const NumericVar *var, int64 ival, int ival_weight,
+ NumericVar *result, int rscale, bool round)
+{
+ NumericDigit *var_digits = var->digits;
+ int var_ndigits = var->ndigits;
+ int res_sign;
+ int res_weight;
+ int res_ndigits;
+ NumericDigit *res_buf;
+ NumericDigit *res_digits;
+ uint64 divisor;
+ int i;
+
+ /* Guard against division by zero */
+ if (ival == 0)
+ ereport(ERROR,
+ errcode(ERRCODE_DIVISION_BY_ZERO),
+ errmsg("division by zero"));
+
+ /* Result zero check */
+ if (var_ndigits == 0)
+ {
+ zero_var(result);
+ result->dscale = rscale;
+ return;
+ }
+
+ /*
+ * Determine the result sign, weight and number of digits to calculate.
+ * The weight figured here is correct if the emitted quotient has no
+ * leading zero digits; otherwise strip_var() will fix things up.
+ */
+ if (var->sign == NUMERIC_POS)
+ res_sign = ival > 0 ? NUMERIC_POS : NUMERIC_NEG;
+ else
+ res_sign = ival > 0 ? NUMERIC_NEG : NUMERIC_POS;
+ res_weight = var->weight - ival_weight;
+ /* The number of accurate result digits we need to produce: */
+ res_ndigits = res_weight + 1 + (rscale + DEC_DIGITS - 1) / DEC_DIGITS;
+ /* ... but always at least 1 */
+ res_ndigits = Max(res_ndigits, 1);
+ /* If rounding needed, figure one more digit to ensure correct result */
+ if (round)
+ res_ndigits++;
+
+ res_buf = digitbuf_alloc(res_ndigits + 1);
+ res_buf[0] = 0; /* spare digit for later rounding */
+ res_digits = res_buf + 1;
+
+ /*
+ * Now compute the quotient digits. This is the short division algorithm
+ * described in Knuth volume 2, section 4.3.1 exercise 16, except that we
+ * allow the divisor to exceed the internal base.
+ *
+ * In this algorithm, the carry from one digit to the next is at most
+ * divisor - 1. Therefore, while processing the next digit, carry may
+ * become as large as divisor * NBASE - 1, and so it requires a 128-bit
+ * integer if this exceeds PG_UINT64_MAX.
+ */
+ divisor = i64abs(ival);
+
+ if (divisor <= PG_UINT64_MAX / NBASE)
+ {
+ /* carry cannot overflow 64 bits */
+ uint64 carry = 0;
+
+ for (i = 0; i < res_ndigits; i++)
+ {
+ carry = carry * NBASE + (i < var_ndigits ? var_digits[i] : 0);
+ res_digits[i] = (NumericDigit) (carry / divisor);
+ carry = carry % divisor;
+ }
+ }
+ else
+ {
+ /* carry may exceed 64 bits */
+ uint128 carry = 0;
+
+ for (i = 0; i < res_ndigits; i++)
+ {
+ carry = carry * NBASE + (i < var_ndigits ? var_digits[i] : 0);
+ res_digits[i] = (NumericDigit) (carry / divisor);
+ carry = carry % divisor;
+ }
+ }
+
+ /* Store the quotient in result */
+ digitbuf_free(result->buf);
+ result->ndigits = res_ndigits;
+ result->buf = res_buf;
+ result->digits = res_digits;
+ result->weight = res_weight;
+ result->sign = res_sign;
+
+ /* Round or truncate to target rscale (and set result->dscale) */
+ if (round)
+ round_var(result, rscale);
+ else
+ trunc_var(result, rscale);
+
+ /* Strip leading/trailing zeroes */
+ strip_var(result);
+}
+#endif
+
/*
* Default scale selection for division
*
--
2.37.1 (Apple Git-137.1)
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16
@ 2023-01-23 05:06 John Naylor <[email protected]>
parent: Joel Jacobson <[email protected]>
1 sibling, 1 reply; 30+ messages in thread
From: John Naylor @ 2023-01-23 05:06 UTC (permalink / raw)
To: Joel Jacobson <[email protected]>; +Cc: Dean Rasheed <[email protected]>; pgsql-hackers
On Sun, Jan 22, 2023 at 10:42 PM Joel Jacobson <[email protected]> wrote:
> I did write the code like you suggest first, but changed it,
> since I realised the extra "else if" needed could be eliminated,
> and thought div_var_int64() wouldn't be slower than div_var_int() since
> I thought 64-bit instructions in general are as fast as 32-bit
instructions,
> on 64-bit platforms.
According to Agner's instruction tables [1], integer division on Skylake
(for example) has a latency of 26 cycles for 32-bit operands, and 42-95
cycles for 64-bit.
[1] https://www.agner.org/optimize/instruction_tables.pdf
--
John Naylor
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16
@ 2023-01-23 12:02 Dean Rasheed <[email protected]>
parent: John Naylor <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Dean Rasheed @ 2023-01-23 12:02 UTC (permalink / raw)
To: John Naylor <[email protected]>; +Cc: Joel Jacobson <[email protected]>; pgsql-hackers
On Mon, 23 Jan 2023 at 05:06, John Naylor <[email protected]> wrote:
>
> According to Agner's instruction tables [1], integer division on Skylake (for example) has a latency of 26 cycles for 32-bit operands, and 42-95 cycles for 64-bit.
>
> [1] https://www.agner.org/optimize/instruction_tables.pdf
>
Thanks, that's a very useful reference.
(And I do indeed have one of those CPUs, which explains what I was seeing.)
Regards,
Dean
^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16
@ 2023-01-23 12:04 Dean Rasheed <[email protected]>
parent: Joel Jacobson <[email protected]>
0 siblings, 0 replies; 30+ messages in thread
From: Dean Rasheed @ 2023-01-23 12:04 UTC (permalink / raw)
To: Joel Jacobson <[email protected]>; +Cc: pgsql-hackers
On Sun, 22 Jan 2023 at 22:49, Joel Jacobson <[email protected]> wrote:
>
> Many thanks for feedback. Nice catch! New patch attached.
>
Cool, that resolves the performance issues I was seeing for smaller
divisors (which also had a noticeable impact on the numeric_big
regression test).
After some more testing, the gains look good to me, and I wasn't able
to find any cases where it made things slower, so I've gone ahead and
pushed it.
Regards,
Dean
^ permalink raw reply [nested|flat] 30+ messages in thread
end of thread, other threads:[~2023-01-23 12:04 UTC | newest]
Thread overview: 30+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v9 06/15] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v7 07/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v8 07/14] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2020-04-03 21:17 [PATCH v6 08/10] doc: backup manifests Justin Pryzby <[email protected]>
2023-01-22 13:41 [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16 Joel Jacobson <[email protected]>
2023-01-22 15:06 ` Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16 Dean Rasheed <[email protected]>
2023-01-22 15:41 ` Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16 Joel Jacobson <[email protected]>
2023-01-22 17:25 ` Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16 Dean Rasheed <[email protected]>
2023-01-22 22:48 ` Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16 Joel Jacobson <[email protected]>
2023-01-23 12:04 ` Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16 Dean Rasheed <[email protected]>
2023-01-23 05:06 ` Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16 John Naylor <[email protected]>
2023-01-23 12:02 ` Re: [PATCH] Use 128-bit math to accelerate numeric division, when 8 < divisor digits <= 16 Dean Rasheed <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox