($INBOX_DIR/description missing)help / color / mirror / Atom feed
[PATCH v7 07/10] doc: backup manifests 23+ messages / 2 participants [nested] [flat]
* [PATCH v7 07/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v8 07/14] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v9 06/15] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* [PATCH v6 08/10] doc: backup manifests @ 2020-04-03 21:17 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 23+ 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] 23+ messages in thread
* Re: [PATCH] llvmjit: always add the simplifycfg pass @ 2026-01-29 13:32 Matheus Alcantara <[email protected]> 0 siblings, 0 replies; 23+ messages in thread From: Matheus Alcantara @ 2026-01-29 13:32 UTC (permalink / raw) To: Andres Freund <[email protected]>; Pierre Ducroquet <[email protected]>; +Cc: [email protected] <[email protected]> On 28/01/26 20:19, Andres Freund wrote: >>> I did some benchmarks on some TPCH queries (1 and 4) and I got these >>> results. Note that for these tests I set jit_optimize_above_cost=1000000 >>> so that it force to use the default<O0> pass with simplifycfg. > > FYI, you can use -1 to just disble it, instead of having to rely on a specific > cost. > Yeap, it's easier to disable at all, thanks for pointing this out. >>> >>> Master Q1: >>> Timing: Generation 1.553 ms (Deform 0.573 ms), Inlining 0.052 ms, Optimization 95.571 ms, Emission 58.941 ms, Total 156.116 ms >>> Execution Time: 38221.318 ms >>> >>> Patch Q1: >>> Timing: Generation 1.477 ms (Deform 0.534 ms), Inlining 0.040 ms, Optimization 95.364 ms, Emission 58.046 ms, Total 154.927 ms >>> Execution Time: 38257.797 ms >>> >>> Master Q4: >>> Timing: Generation 0.836 ms (Deform 0.309 ms), Inlining 0.086 ms, Optimization 5.098 ms, Emission 6.963 ms, Total 12.983 ms >>> Execution Time: 19512.134 ms >>> >>> Patch Q4: >>> Timing: Generation 0.802 ms (Deform 0.294 ms), Inlining 0.090 ms, Optimization 5.234 ms, Emission 6.521 ms, Total 12.648 ms >>> Execution Time: 16051.483 ms >>> >>> >>> For Q4 I see a small increase on Optimization phase but we have a good >>> performance improvement on execution time. For Q1 the results are almost >>> the same. > > These queries are all simple enough that I'm not sure this is a particularly > good benchmark for optimization speed. In particular, the deform routines > don't have to deal with a lot of columns and there aren't a lot of functions > (although I guess that shouldn't really matter WRT simplifycfg). Thanks for the insight. Do you know any other query from TPCH or any other benchmark suite that we could use to get more realistic results? -- Matheus Alcantara EDB: https://www.enterprisedb.com ^ permalink raw reply [nested|flat] 23+ messages in thread
end of thread, other threads:[~2026-01-29 13:32 UTC | newest] Thread overview: 23+ 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 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]> 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 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 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 v6 08/10] doc: backup manifests Justin Pryzby <[email protected]> 2026-01-29 13:32 Re: [PATCH] llvmjit: always add the simplifycfg pass Matheus Alcantara <[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