From: Peter Eisentraut Date: Sun, 7 Jun 2020 12:07:33 +0000 (+0200) Subject: doc: Move options on man pages into more alphabetical order X-Git-Tag: REL_13_BETA2~61 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=b25da866152347109943f998b66b1a320a9de3e0;p=thirdparty%2Fpostgresql.git doc: Move options on man pages into more alphabetical order --- diff --git a/doc/src/sgml/ref/dropdb.sgml b/doc/src/sgml/ref/dropdb.sgml index 28b18bfcb0c..ded85b0e232 100644 --- a/doc/src/sgml/ref/dropdb.sgml +++ b/doc/src/sgml/ref/dropdb.sgml @@ -77,23 +77,23 @@ PostgreSQL documentation - - + + - Issues a verification prompt before doing anything destructive. + Attempt to terminate all existing connections to the target database + before dropping it. See for more + information on this option. - - + + - Attempt to terminate all existing connections to the target database - before dropping it. See for more - information on this option. + Issues a verification prompt before doing anything destructive. diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml index e3cc08e485e..cf099ccbcab 100644 --- a/doc/src/sgml/ref/pg_basebackup.sgml +++ b/doc/src/sgml/ref/pg_basebackup.sgml @@ -500,39 +500,51 @@ PostgreSQL documentation - + - This option prevents the creation of a temporary replication slot - during the backup even if it's supported by the server. + Specifies the checksum algorithm that should be applied to each file + included in the backup manifest. Currently, the available + algorithms are NONE, CRC32C, + SHA224, SHA256, + SHA384, and SHA512. + The default is CRC32C. - Temporary replication slots are created by default if no slot name - is given with the option when using log streaming. + If NONE is selected, the backup manifest will + 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 SHA256 + checksum of its own contents. The SHA algorithms + are significantly more CPU-intensive than CRC32C, + so selecting one of them may increase the time required to complete + the backup. - The main purpose of this option is to allow taking a base backup when - the server is out of free replication slots. Using replication slots - is almost always preferred, because it prevents needed WAL from being - removed by the server during the backup. + Using a SHA hash function provides a cryptographically secure digest + of each file for users who wish to verify that the backup has not been + tampered with, while the CRC32C algorithm provides a checksum which is + much faster to calculate and good at catching errors due to accidental + changes but is not resistant to targeted 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. + + + can be used to check the + integrity of a backup against the backup manifest. - + - Disables verification of checksums, if they are enabled on the server - the base backup is taken from. - - - By default, checksums are verified and checksum failures will result - in a non-zero exit status. However, the base backup will not be - removed in such a case, as if the option - had been used. Checksum verifications failures will also be reported - in the - pg_stat_database view. + Forces all filenames in the backup manifest to be hex-encoded. + If this option is not specified, only non-UTF8 filenames are + hex-encoded. This option is mostly intended to test that tools which + read a backup manifest file properly handle this case. @@ -576,51 +588,39 @@ PostgreSQL documentation - + - Forces all filenames in the backup manifest to be hex-encoded. - If this option is not specified, only non-UTF8 filenames are - hex-encoded. This option is mostly intended to test that tools which - read a backup manifest file properly handle this case. + This option prevents the creation of a temporary replication slot + during the backup even if it's supported by the server. + + + Temporary replication slots are created by default if no slot name + is given with the option when using log streaming. + + + The main purpose of this option is to allow taking a base backup when + the server is out of free replication slots. Using replication slots + is almost always preferred, because it prevents needed WAL from being + removed by the server during the backup. - + - Specifies the checksum algorithm that should be applied to each file - included in the backup manifest. Currently, the available - algorithms are NONE, CRC32C, - SHA224, SHA256, - SHA384, and SHA512. - The default is CRC32C. - - - If NONE is selected, the backup manifest will - 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 SHA256 - checksum of its own contents. The SHA algorithms - are significantly more CPU-intensive than CRC32C, - so selecting one of them may increase the time required to complete - the backup. - - - Using a SHA hash function provides a cryptographically secure digest - of each file for users who wish to verify that the backup has not been - tampered with, while the CRC32C algorithm provides a checksum which is - much faster to calculate and good at catching errors due to accidental - changes but is not resistant to targeted 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. + Disables verification of checksums, if they are enabled on the server + the base backup is taken from. - can be used to check the - integrity of a backup against the backup manifest. + By default, checksums are verified and checksum failures will result + in a non-zero exit status. However, the base backup will not be + removed in such a case, as if the option + had been used. Checksum verifications failures will also be reported + in the + pg_stat_database view. diff --git a/doc/src/sgml/ref/pg_dumpall.sgml b/doc/src/sgml/ref/pg_dumpall.sgml index 40ca31bfdfe..541269d376d 100644 --- a/doc/src/sgml/ref/pg_dumpall.sgml +++ b/doc/src/sgml/ref/pg_dumpall.sgml @@ -287,18 +287,6 @@ PostgreSQL documentation - - - - - Use the specified value of extra_float_digits when dumping - floating-point data, instead of the maximum available precision. - Routine dumps made for backup purposes should not use this option. - - - - - @@ -318,6 +306,17 @@ PostgreSQL documentation + + + + + Use the specified value of extra_float_digits when dumping + floating-point data, instead of the maximum available precision. + Routine dumps made for backup purposes should not use this option. + + + + diff --git a/doc/src/sgml/ref/pg_rewind.sgml b/doc/src/sgml/ref/pg_rewind.sgml index 391e5db2e2f..9ae1bf3ab6e 100644 --- a/doc/src/sgml/ref/pg_rewind.sgml +++ b/doc/src/sgml/ref/pg_rewind.sgml @@ -178,23 +178,6 @@ PostgreSQL documentation - - - - - pg_rewind requires that the target server - is cleanly shut down before rewinding. By default, if the target server - is not shut down cleanly, pg_rewind starts - the target server in single-user mode to complete crash recovery first, - and stops it. - By passing this option, pg_rewind skips - this and errors out immediately if the server is not cleanly shut - down. Users are expected to handle the situation themselves in that - case. - - - - @@ -268,6 +251,23 @@ PostgreSQL documentation + + + + + pg_rewind requires that the target server + is cleanly shut down before rewinding. By default, if the target server + is not shut down cleanly, pg_rewind starts + the target server in single-user mode to complete crash recovery first, + and stops it. + By passing this option, pg_rewind skips + this and errors out immediately if the server is not cleanly shut + down. Users are expected to handle the situation themselves in that + case. + + + + diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index f5a51d3732d..aa2076de407 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++ b/doc/src/sgml/ref/pgbench.sgml @@ -336,26 +336,26 @@ pgbench options d - + Create a partitioned pgbench_accounts table with - NUM partitions of nearly equal size for - the scaled number of accounts. - Default is 0, meaning no partitioning. + NAME method. + Expected values are range or hash. + This option requires that is set to non-zero. + If unspecified, default is range. - + Create a partitioned pgbench_accounts table with - NAME method. - Expected values are range or hash. - This option requires that is set to non-zero. - If unspecified, default is range. + NUM partitions of nearly equal size for + the scaled number of accounts. + Default is 0, meaning no partitioning. @@ -670,16 +670,6 @@ pgbench options d - - scriptname - - - Show the actual code of builtin script scriptname - on stderr, and exit immediately. - - - - transactions transactions @@ -750,13 +740,13 @@ pgbench options d - SEED + seed Set random generator seed. Seeds the system random number generator, which then produces a sequence of initial generator states, one for each thread. - Values for SEED may be: + Values for seed may be: time (the default, the seed is based on the current time), rand (use a strong random source, failing if none is available), or an unsigned decimal integer value. @@ -764,7 +754,7 @@ pgbench options d (random... functions) or implicitly (for instance option uses it to schedule transactions). When explicitly set, the value used for seeding is shown on the terminal. - Any value allowed for SEED may also be + Any value allowed for seed may also be provided through the environment variable PGBENCH_RANDOM_SEED. To ensure that the provided seed impacts all possible uses, put this option @@ -804,6 +794,16 @@ pgbench options d + + scriptname + + + Show the actual code of builtin script scriptname + on stderr, and exit immediately. + + + +