-
+
- 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.
-
+
- 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.
-
+
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.
-
- scriptname
-
- Show the actual code of builtin script scriptname
- on stderr, and exit immediately.
-
-
-
-
transactions
transactions
- 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.
(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
+
+ scriptname
+
+ Show the actual code of builtin script scriptname
+ on stderr, and exit immediately.
+
+
+
+
projects / postgresql.git / commitdiff