What changed?

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: s
 enumvals: None
 
-Write a message to the server log if checkpoints caused by the filling of checkpoint segment files happen closer together than this many seconds (which suggests that max_wal_size ought to be raised). The default is 30 seconds (30s). Zero disables the warning. No warnings will be generated if checkpoint_timeout is less than checkpoint_warning. This parameter can only be set in the postgresql.conf file or on the server command line.
+Write a message to the server log if checkpoints caused by the filling of WAL segment files happen closer together than this many seconds (which suggests that max_wal_size ought to be raised). The default is 30 seconds (30s). Zero disables the warning. No warnings will be generated if checkpoint_timeout is less than checkpoint_warning. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: ['partition', 'on', 'off']
 
-Controls the query planner's use of table constraints to optimize queries. The allowed values of constraint_exclusion are on (examine constraints for all tables), off (never examine constraints), and partition (examine constraints only for inheritance child tables and UNION ALL subqueries). partition is the default setting. It is often used with inheritance and partitioned tables to improve performance. When this parameter allows it for a particular table, the planner compares query conditions with the table's CHECK constraints, and omits scanning tables for which the conditions contradict the constraints. For example: CREATE TABLE parent(key integer, ...); CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent); CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent); ... SELECT * FROM parent WHERE key = 2400; With constraint exclusion enabled, this SELECT will not scan child1000 at all, improving performance. Currently, constraint exclusion is enabled by default only for cases that are often used to implement table partitioning. Turning it on for all tables imposes extra planning overhead that is quite noticeable on simple queries, and most often will yield no benefit for simple queries. If you have no partitioned tables you might prefer to turn it off entirely. Refer to Section 5.10.4 for more information on using constraint exclusion and partitioning.
+Controls the query planner's use of table constraints to optimize queries. The allowed values of constraint_exclusion are on (examine constraints for all tables), off (never examine constraints), and partition (examine constraints only for inheritance child tables and UNION ALL subqueries). partition is the default setting. It is often used with traditional inheritance trees to improve performance. When this parameter allows it for a particular table, the planner compares query conditions with the table's CHECK constraints, and omits scanning tables for which the conditions contradict the constraints. For example: CREATE TABLE parent(key integer, ...); CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent); CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent); ... SELECT * FROM parent WHERE key = 2400; With constraint exclusion enabled, this SELECT will not scan child1000 at all, improving performance. Currently, constraint exclusion is enabled by default only for cases that are often used to implement table partitioning via inheritance trees. Turning it on for all tables imposes extra planning overhead that is quite noticeable on simple queries, and most often will yield no benefit for simple queries. If you have no tables that are partitioned using traditional inheritance, you might prefer to turn it off entirely. (Note that the equivalent feature for partitioned tables is controlled by a separate parameter, enable_partition_pruning.) Refer to Section 5.10.5 for more information on using constraint exclusion to implement partitioning.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: integer
+context: internal
+boot_val: 448
+unit: None
+enumvals: None
+
+On Unix systems this parameter reports the permissions of the data directory defined by (data_directory) at startup. (On Microsoft Windows this parameter will always display 0700). See group access for more information.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-Enables or disables the query planner's use of index-only-scan plan types (see Section 11.11). The default is on.
+Enables or disables the query planner's use of index-only-scan plan types (see Section 11.9). The default is on.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: bool
+context: user
+boot_val: on
+unit: None
+enumvals: None
+
+Enables or disables the query planner's use of parallel-aware append plan types. The default is on.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: bool
+context: user
+boot_val: on
+unit: None
+enumvals: None
+
+Enables or disables the query planner's use of hash-join plan types with parallel hash. Has no effect if hash-join plans are not also enabled. The default is on.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: bool
+context: user
+boot_val: on
+unit: None
+enumvals: None
+
+Enables or disables the query planner's ability to eliminate a partitioned table's partitions from query plans. This also controls the planner's ability to generate query plans which allow the query executor to remove (ignore) partitions during query execution. The default is on. See Section 5.10.4 for details.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: bool
+context: user
+boot_val: off
+unit: None
+enumvals: None
+
+Enables or disables the query planner's use of partitionwise grouping or aggregation, which allows grouping or aggregation on partitioned tables to be performed separately for each partition. If the GROUP BY clause does not include the partition keys, only partial aggregation can be performed on a per-partition basis, and finalization must be performed later. Because partitionwise grouping or aggregation can use significantly more CPU time and memory during planning, the default is off.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: bool
+context: user
+boot_val: off
+unit: None
+enumvals: None
+
+Enables or disables the query planner's use of partitionwise join, which allows a join between partitioned tables to be performed by joining the matching partitions. Partitionwise join currently applies only when the join conditions include all the partition keys, which must be of the same data type and have exactly matching sets of child partitions. Because partitionwise join planning can use significantly more CPU time and memory during planning, the default is off.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-Soft upper limit of the size of the set returned by GIN index scans. For more information see Section 64.5.
+Soft upper limit of the size of the set returned by GIN index scans. For more information see Section 66.5.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: kB
 enumvals: None
 
-Sets the maximum size of the GIN pending list which is used when fastupdate is enabled. If the list grows larger than this maximum size, it is cleaned up by moving the entries in it to the main GIN data structure in bulk. The default is four megabytes (4MB). This setting can be overridden for individual GIN indexes by changing index storage parameters. See Section 64.4.1 and Section 64.5 for more information.
+Sets the maximum size of the GIN pending list which is used when fastupdate is enabled. If the list grows larger than this maximum size, it is cleaned up by moving the entries in it to the main GIN data structure in bulk. The default is four megabytes (4MB). This setting can be overridden for individual GIN indexes by changing index storage parameters. See Section 66.4.1 and Section 66.5 for more information.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: ['off', 'on', 'try']
 
-Enables/disables the use of huge memory pages. Valid values are try (the default), on, and off. At present, this feature is supported only on Linux. The setting is ignored on other systems when set to try. The use of huge pages results in smaller page tables and less CPU time spent on memory management, increasing performance. For more details, see Section 18.4.5. With huge_pages set to try, the server will try to use huge pages, but fall back to using normal allocation if that fails. With on, failure to use huge pages will prevent the server from starting up. With off, huge pages will not be used.
+Controls whether huge pages are requested for the main shared memory area. Valid values are try (the default), on, and off. With huge_pages set to try, the server will try to request huge pages, but fall back to the default if that fails. With on, failure to request huge pages will prevent the server from starting up. With off, huge pages will not be requested. At present, this setting is supported only on Linux and Windows. The setting is ignored on other systems when set to try. The use of huge pages results in smaller page tables and less CPU time spent on memory management, increasing performance. For more details about using huge pages on Linux, see Section 18.4.5. Huge pages are known as large pages on Windows. To use them, you need to assign the user right Lock Pages in Memory to the Windows user account that runs PostgreSQL. You can use Windows Group Policy tool (gpedit.msc) to assign the user right Lock Pages in Memory. To start the database server on the command prompt as a standalone process, not as a Windows service, the command prompt must be run as an administrator or User Access Control (UAC) must be disabled. When the UAC is enabled, the normal command prompt revokes the user right Lock Pages in Memory when started. Note that this setting only affects the main shared memory area. Operating systems such as Linux, FreeBSD, and Illumos can also use huge pages (also known as “super” pages or “large” pages) automatically for normal memory allocation, without an explicit request from PostgreSQL. On Linux, this is called “transparent huge pages” (THP). That feature has been known to cause performance degradation with PostgreSQL for some users on some Linux versions, so its use is currently discouraged (unlike explicit use of huge_pages).

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: bool
+context: user
+boot_val: off
+unit: None
+enumvals: None
+
+Determines whether JIT compilation may be used by PostgreSQL, if available (see Chapter 32). The default is off.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: real
+context: user
+boot_val: 100000
+unit: None
+enumvals: None
+
+Sets the query cost above which JIT compilation is activated, if enabled (see Chapter 32). Performing JIT costs planning time but can accelerate query execution. Setting this to -1 disables JIT compilation. The default is 100000.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: bool
+context: superuser-backend
+boot_val: off
+unit: None
+enumvals: None
+
+If LLVM has the required functionality, register generated functions with GDB. This makes debugging easier. The default setting is off. This parameter can only be set at server start.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: bool
+context: superuser
+boot_val: off
+unit: None
+enumvals: None
+
+Writes the generated LLVM IR out to the file system, inside data_directory. This is only useful for working on the internals of the JIT implementation. The default setting is off. This parameter can only be changed by a superuser.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: bool
+context: user
+boot_val: on
+unit: None
+enumvals: None
+
+Determines whether expressions are JIT compiled, when JIT compilation is activated (see Section 32.2). The default is on.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: real
+context: user
+boot_val: 500000
+unit: None
+enumvals: None
+
+Sets the query cost above which JIT compilation attempts to inline functions and operators. Inlining adds planning time, but can improve execution speed. It is not meaningful to set this to less than jit_above_cost. Setting this to -1 disables inlining. The default is 500000.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: real
+context: user
+boot_val: 500000
+unit: None
+enumvals: None
+
+Sets the query cost above which JIT compilation applies expensive optimizations. Such optimization adds planning time, but can improve execution speed. It is not meaningful to set this to less than jit_above_cost, and it is unlikely to be beneficial to set it to more than jit_inline_above_cost. Setting this to -1 disables expensive optimizations. The default is 500000.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: bool
+context: superuser-backend
+boot_val: off
+unit: None
+enumvals: None
+
+If LLVM has the required functionality, emit the data needed to allow perf to profile functions generated by JIT. This writes out files to $HOME/.debug/jit/; the user is responsible for performing cleanup when desired. The default setting is off. This parameter can only be set at server start.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: string
+context: postmaster
+boot_val: llvmjit
+unit: None
+enumvals: None
+
+This variable is the name of the JIT provider library to be used (see Section 32.4.2). The default is llvmjit. This parameter can only be set at server start. If set to a non-existent library, JIT will not be available, but no error will be raised. This allows JIT support to be installed separately from the main PostgreSQL package.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: bool
+context: user
+boot_val: on
+unit: None
+enumvals: None
+
+Determines whether tuple deforming is JIT compiled, when JIT compilation is activated (see Section 32.2). The default is on.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-Sets the location of the Kerberos server key file. See Section 20.3.3 for details. This parameter can only be set in the postgresql.conf file or on the server command line.
+Sets the location of the Kerberos server key file. See Section 20.6 for details. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-Specifies the TCP/IP address(es) on which the server is to listen for connections from client applications. The value takes the form of a comma-separated list of host names and/or numeric IP addresses. The special entry * corresponds to all available IP interfaces. The entry 0.0.0.0 allows listening for all IPv4 addresses and :: allows listening for all IPv6 addresses. If the list is empty, the server does not listen on any IP interface at all, in which case only Unix-domain sockets can be used to connect to it. The default value is localhost, which allows only local TCP/IP “loopback” connections to be made. While client authentication (Chapter 20) allows fine-grained control over who can access the server, listen_addresses controls which interfaces accept connection attempts, which can help prevent repeated malicious connection requests on insecure network interfaces. This parameter can only be set at server start.
+Specifies the TCP/IP address(es) on which the server is to listen for connections from client applications. The value takes the form of a comma-separated list of host names and/or numeric IP addresses. The special entry * corresponds to all available IP interfaces. The entry 0.0.0.0 allows listening for all IPv4 addresses and :: allows listening for all IPv6 addresses. If the list is empty, the server does not listen on any IP interface at all, in which case only Unix-domain sockets can be used to connect to it. If the list is not empty, the server will start if it can listen on at least one TCP/IP address. A warning will be emitted for any TCP/IP address which cannot be opened. The default value is localhost, which allows only local TCP/IP “loopback” connections to be made. While client authentication (Chapter 20) allows fine-grained control over who can access the server, listen_addresses controls which interfaces accept connection attempts, which can help prevent repeated malicious connection requests on insecure network interfaces. This parameter can only be set at server start.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-In PostgreSQL releases prior to 9.0, large objects did not have access privileges and were, therefore, always readable and writable by all users. Setting this variable to on disables the new privilege checks, for compatibility with prior releases. The default is off. Only superusers can change this setting. Setting this variable does not disable all security checks related to large objects — only those for which the default behavior has changed in PostgreSQL 9.0. For example, lo_import() and lo_export() need superuser privileges regardless of this setting.
+In PostgreSQL releases prior to 9.0, large objects did not have access privileges and were, therefore, always readable and writable by all users. Setting this variable to on disables the new privilege checks, for compatibility with prior releases. The default is off. Only superusers can change this setting. Setting this variable does not disable all security checks related to large objects — only those for which the default behavior has changed in PostgreSQL 9.0.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: ms
 enumvals: None
 
-Causes each action executed by autovacuum to be logged if it ran for at least the specified number of milliseconds. Setting this to zero logs all autovacuum actions. Minus-one (the default) disables logging autovacuum actions. For example, if you set this to 250ms then all automatic vacuums and analyzes that run 250ms or longer will be logged. In addition, when this parameter is set to any value other than -1, a message will be logged if an autovacuum action is skipped due to the existence of a conflicting lock. Enabling this parameter can be helpful in tracking autovacuum activity. This parameter can only be set in the postgresql.conf file or on the server command line; but the setting can be overridden for individual tables by changing table storage parameters.
+Causes each action executed by autovacuum to be logged if it ran for at least the specified number of milliseconds. Setting this to zero logs all autovacuum actions. Minus-one (the default) disables logging autovacuum actions. For example, if you set this to 250ms then all automatic vacuums and analyzes that run 250ms or longer will be logged. In addition, when this parameter is set to any value other than -1, a message will be logged if an autovacuum action is skipped due to a conflicting lock or a concurrently dropped relation. Enabling this parameter can be helpful in tracking autovacuum activity. This parameter can only be set in the postgresql.conf file or on the server command line; but the setting can be overridden for individual tables by changing table storage parameters.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-Causes each replication command to be logged in the server log. See Section 52.4 for more information about replication command. The default value is off. Only superusers can change this setting.
+Causes each replication command to be logged in the server log. See Section 53.4 for more information about replication command. The default value is off. Only superusers can change this setting.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: integer
+context: user
+boot_val: 2
+unit: None
+enumvals: None
+
+Sets the maximum number of parallel workers that can be started by a single utility command. Currently, the only parallel utility command that supports the use of parallel workers is CREATE INDEX, and only when building a B-tree index. Parallel workers are taken from the pool of processes established by max_worker_processes, limited by max_parallel_workers. Note that the requested number of workers may not actually be available at run time. If this occurs, the utility operation will run with fewer workers than expected. The default value is 2. Setting this value to 0 disables the use of parallel workers by utility commands. Note that parallel utility commands should not consume substantially more memory than equivalent non-parallel operations. This strategy differs from that of parallel query, where resource limits generally apply per worker process. Parallel utility commands treat the resource limit maintenance_work_mem as a limit to be applied to the entire utility command, regardless of the number of parallel worker processes. However, parallel utility commands may still consume substantially more CPU resources and I/O bandwidth.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-Sets the maximum number of workers that the system can support for parallel queries. The default value is 8. When increasing or decreasing this value, consider also adjusting max_parallel_workers_per_gather. Also, note that a setting for this value which is higher than max_worker_processes will have no effect, since parallel workers are taken from the pool of worker processes established by that setting.
+Sets the maximum number of workers that the system can support for parallel operations. The default value is 8. When increasing or decreasing this value, consider also adjusting max_parallel_maintenance_workers and max_parallel_workers_per_gather. Also, note that a setting for this value which is higher than max_worker_processes will have no effect, since parallel workers are taken from the pool of worker processes established by that setting.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-Specifies the maximum number of replication slots (see Section 26.2.6) that the server can support. The default is 10. This parameter can only be set at server start. wal_level must be set to replica or higher to allow replication slots to be used. Setting it to a lower value than the number of currently existing replication slots will prevent the server from starting. On the subscriber side, specifies how many replication origins (see Chapter 49) can be tracked simultaneously, effectively limiting how many logical replication subscriptions can be created on the server. Setting it a lower value than the current number of tracked replication origins (reflected in pg_replication_origin_status, not pg_replication_origin) will prevent the server from starting.
+Specifies the maximum number of replication slots (see Section 26.2.6) that the server can support. The default is 10. This parameter can only be set at server start. Setting it to a lower value than the number of currently existing replication slots will prevent the server from starting. Also, wal_level must be set to replica or higher to allow replication slots to be used. On the subscriber side, specifies how many replication origins (see Chapter 50) can be tracked simultaneously, effectively limiting how many logical replication subscriptions can be created on the server. Setting it a lower value than the current number of tracked replication origins (reflected in pg_replication_origin_status, not pg_replication_origin) will prevent the server from starting.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-Specifies the maximum number of concurrent connections from standby servers or streaming base backup clients (i.e., the maximum number of simultaneously running WAL sender processes). The default is 10. The value 0 means replication is disabled. WAL sender processes count towards the total number of connections, so the parameter cannot be set higher than max_connections. Abrupt streaming client disconnection might cause an orphaned connection slot until a timeout is reached, so this parameter should be set slightly higher than the maximum number of expected clients so disconnected clients can immediately reconnect. This parameter can only be set at server start. wal_level must be set to replica or higher to allow connections from standby servers.
+Specifies the maximum number of concurrent connections from standby servers or streaming base backup clients (i.e., the maximum number of simultaneously running WAL sender processes). The default is 10. The value 0 means replication is disabled. WAL sender processes count towards the total number of connections, so this parameter's value must be less than max_connections minus superuser_reserved_connections. Abrupt streaming client disconnection might leave an orphaned connection slot behind until a timeout is reached, so this parameter should be set slightly higher than the maximum number of expected clients so disconnected clients can immediately reconnect. This parameter can only be set at server start. Also, wal_level must be set to replica or higher to allow connections from standby servers.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-Sets the maximum number of background processes that the system can support. This parameter can only be set at server start. The default is 8. When running a standby server, you must set this parameter to the same or higher value than on the master server. Otherwise, queries will not be allowed in the standby server. When changing this value, consider also adjusting max_parallel_workers and max_parallel_workers_per_gather.
+Sets the maximum number of background processes that the system can support. This parameter can only be set at server start. The default is 8. When running a standby server, you must set this parameter to the same or higher value than on the master server. Otherwise, queries will not be allowed in the standby server. When changing this value, consider also adjusting max_parallel_workers, max_parallel_maintenance_workers, and max_parallel_workers_per_gather.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: bool
+context: user
+boot_val: on
+unit: None
+enumvals: None
+
+Allows the leader process to execute the query plan under Gather and Gather Merge nodes instead of waiting for worker processes. The default is on. Setting this value to off reduces the likelihood that workers will become blocked because the leader is not reading tuples fast enough, but requires the leader process to wait for worker processes to start up before the first tuples can be produced. The degree to which the leader can help or hinder performance depends on the plan type, number of workers and query duration.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: ['md5', 'scram-sha-256']
 
-When a password is specified in CREATE ROLE or ALTER ROLE, this parameter determines the algorithm to use to encrypt the password. The default value is md5, which stores the password as an MD5 hash (on is also accepted, as alias for md5). Setting this parameter to scram-sha-256 will encrypt the password with SCRAM-SHA-256. Note that older clients might lack support for the SCRAM authentication mechanism, and hence not work with passwords encrypted with SCRAM-SHA-256. See Section 20.3.2 for more details.
+When a password is specified in CREATE ROLE or ALTER ROLE, this parameter determines the algorithm to use to encrypt the password. The default value is md5, which stores the password as an MD5 hash (on is also accepted, as alias for md5). Setting this parameter to scram-sha-256 will encrypt the password with SCRAM-SHA-256. Note that older clients might lack support for the SCRAM authentication mechanism, and hence not work with passwords encrypted with SCRAM-SHA-256. See Section 20.5 for more details.

--- 10
+++ 11
@@ -1,7 +0,0 @@
-vartype: integer
-context: user
-boot_val: 150000
-unit: None
-enumvals: None
-
-When the number of tuples to be sorted is smaller than this number, a sort will produce its first output run using replacement selection rather than quicksort. This may be useful in memory-constrained environments where tuples that are input into larger sort operations have a strong physical-to-logical correlation. Note that this does not include input tuples with an inverse correlation. It is possible for the replacement selection algorithm to generate one long run that requires no merging, where use of the default strategy would result in many runs that must be merged to produce a final sorted output. This may allow sort operations to complete sooner. The default is 150,000 tuples. Note that higher values are typically not much more effective, and may be counter-productive, since the priority queue is sensitive to the size of available CPU cache, whereas the default strategy sorts runs using a cache oblivious algorithm. This property allows the default sort strategy to automatically and transparently make effective use of available CPU cache. Setting maintenance_work_mem to its default value usually prevents utility command external sorts (e.g., sorts used by CREATE INDEX to build B-Tree indexes) from ever using replacement selection sort, unless the input tuples are quite wide.

--- 10
+++ 11
@@ -1,6 +1,6 @@
 vartype: string
 context: internal
-boot_val: 10.23 (Debian 10.23-1.pgdg110+1)
+boot_val: 11.22 (Debian 11.22-1.pgdg120+1)
 unit: None
 enumvals: None
 

--- 10
+++ 11
@@ -1,6 +1,6 @@
 vartype: integer
 context: internal
-boot_val: 100023
+boot_val: 110022
 unit: None
 enumvals: None
 

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: ['origin', 'replica', 'local']
 
-Controls firing of replication-related triggers and rules for the current session. Setting this variable requires superuser privilege and results in discarding any previously cached query plans. Possible values are origin (the default), replica and local. See ALTER TABLE for more information.
+Controls firing of replication-related triggers and rules for the current session. Setting this variable requires superuser privilege and results in discarding any previously cached query plans. Possible values are origin (the default), replica and local. The intended use of this setting is that logical replication systems set it to replica when they are applying replicated changes. The effect of that will be that triggers and rules (that have not been altered from their default configuration) will not fire on the replica. See the ALTER TABLE clauses ENABLE TRIGGER and ENABLE RULE for more information. PostgreSQL treats the settings origin and local the same internally. Third-party replication systems may use these two values for their internal purposes, for example using local to designate a session whose changes should not be replicated. Since foreign keys are implemented as triggers, setting this parameter to replica also disables all foreign key checks, which can leave data in an inconsistent state if improperly used.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-Enables SSL connections. Please read Section 18.9 before using this. This parameter can only be set in the postgresql.conf file or on the server command line. The default is off.
+Enables SSL connections. This parameter can only be set in the postgresql.conf file or on the server command line. The default is off.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-Specifies the name of the file containing the SSL server certificate authority (CA). Relative paths are relative to the data directory. This parameter can only be set in the postgresql.conf file or on the server command line. The default is empty, meaning no CA file is loaded, and client certificate verification is not performed. In previous releases of PostgreSQL, the name of this file was hard-coded as root.crt.
+Specifies the name of the file containing the SSL server certificate authority (CA). Relative paths are relative to the data directory. This parameter can only be set in the postgresql.conf file or on the server command line. The default is empty, meaning no CA file is loaded, and client certificate verification is not performed.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-Specifies the name of the file containing the SSL client certificate revocation list (CRL). Relative paths are relative to the data directory. This parameter can only be set in the postgresql.conf file or on the server command line. The default is empty, meaning no CRL file is loaded. In previous releases of PostgreSQL, the name of this file was hard-coded as root.crl.
+Specifies the name of the file containing the SSL client certificate revocation list (CRL). Relative paths are relative to the data directory. This parameter can only be set in the postgresql.conf file or on the server command line. The default is empty, meaning no CRL file is loaded.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: string
+context: sighup
+boot_val: 
+unit: None
+enumvals: None
+
+Sets an external command to be invoked when a passphrase for decrypting an SSL file such as a private key needs to be obtained. By default, this parameter is empty, which means the built-in prompting mechanism is used. The command must print the passphrase to the standard output and exit with code 0. In the parameter value, %p is replaced by a prompt string. (Write %% for a literal %.) Note that the prompt string will probably contain whitespace, so be sure to quote adequately. A single newline is stripped from the end of the output if present. The command does not actually have to prompt the user for a passphrase. It can read it from a file, obtain it from a keychain facility, or similar. It is up to the user to make sure the chosen mechanism is adequately secure. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: bool
+context: sighup
+boot_val: off
+unit: None
+enumvals: None
+
+This parameter determines whether the passphrase command set by ssl_passphrase_command will also be called during a configuration reload if a key file needs a passphrase. If this parameter is false (the default), then ssl_passphrase_command will be ignored during a reload and the SSL configuration will not be reloaded if a passphrase is needed. That setting is appropriate for a command that requires a TTY for prompting, which might not be available when the server is running. Setting this parameter to true might be appropriate if the passphrase is obtained from a file, for example. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: None
 enumvals: None
 
-Determines the number of connection “slots” that are reserved for connections by PostgreSQL superusers. At most max_connections connections can ever be active simultaneously. Whenever the number of active concurrent connections is at least max_connections minus superuser_reserved_connections, new connections will be accepted only for superusers, and no new replication connections will be accepted. The default value is three connections. The value must be less than the value of max_connections. This parameter can only be set at server start.
+Determines the number of connection “slots” that are reserved for connections by PostgreSQL superusers. At most max_connections connections can ever be active simultaneously. Whenever the number of active concurrent connections is at least max_connections minus superuser_reserved_connections, new connections will be accepted only for superusers, and no new replication connections will be accepted. The default value is three connections. The value must be less than max_connections minus max_wal_senders. This parameter can only be set at server start.

--- 10
+++ 11
@@ -1,7 +1,7 @@
 vartype: integer
 context: postmaster
 boot_val: 1024
-unit: None
+unit: B
 enumvals: None
 
 Specifies the number of bytes reserved to track the currently executing command for each active session, for the pg_stat_activity.query field. The default value is 1024. This parameter can only be set at server start.

--- 10
+++ 11
@@ -0,0 +1,7 @@
+vartype: real
+context: user
+boot_val: 0.1
+unit: None
+enumvals: None
+
+Specifies the fraction of the total number of heap tuples counted in the previous statistics collection that can be inserted without incurring an index scan at the VACUUM cleanup stage. This setting currently applies to B-tree indexes only. If no tuples were deleted from the heap, B-tree indexes are still scanned at the VACUUM cleanup stage when at least one of the following conditions is met: the index statistics are stale, or the index contains deleted pages that can be recycled during cleanup. Index statistics are considered to be stale if the number of newly inserted tuples exceeds the vacuum_cleanup_index_scale_factor fraction of the total number of heap tuples detected by the previous statistics collection. The total number of heap tuples is stored in the index meta-page. Note that the meta-page does not include this data until VACUUM finds no dead tuples, so B-tree index scan at the cleanup stage can only be skipped if the second and subsequent VACUUM cycles detect no dead tuples. The value can range from 0 to 10000000000. When vacuum_cleanup_index_scale_factor is set to 0, index scans are never skipped during VACUUM cleanup. The default value is 0.1.

--- 10
+++ 11
@@ -1,7 +1,7 @@
 vartype: integer
 context: internal
-boot_val: 2048
-unit: 8kB
+boot_val: 16777216
+unit: B
 enumvals: None
 
-Reports the number of blocks (pages) in a WAL segment file. The total size of a WAL segment file in bytes is equal to wal_segment_size multiplied by wal_block_size; by default this is 16MB. See Section 30.4 for more information.
+Reports the size of write ahead log segments. The default value is 16MB. See Section 30.4 for more information.

--- 10
+++ 11
@@ -4,4 +4,4 @@
 unit: kB
 enumvals: None
 
-Specifies the amount of memory to be used by internal sort operations and hash tables before writing to temporary disk files. The value defaults to four megabytes (4MB). Note that for a complex query, several sort or hash operations might be running in parallel; each operation will be allowed to use as much memory as this value specifies before it starts to write data into temporary files. Also, several running sessions could be doing such operations concurrently. Therefore, the total memory used could be many times the value of work_mem; it is necessary to keep this fact in mind when choosing the value. Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables are used in hash joins, hash-based aggregation, and hash-based processing of IN subqueries.
+Specifies the amount of memory to be used by internal sort operations and hash tables before writing to temporary disk files. The value defaults to four megabytes (4MB). Note that a complex query might perform several sort and hash operations at the same time, with each operation generally being allowed to use as much memory as this value specifies before it starts to write data into temporary files. Also, several running sessions could be doing such operations concurrently. Therefore, the total memory used could be many times the value of work_mem; it is necessary to keep this fact in mind when choosing the value. Sort operations are used for ORDER BY, DISTINCT, and merge joins. Hash tables are used in hash joins, hash-based aggregation, and hash-based processing of IN subqueries.