What changed?

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Sets the time zone for displaying and interpreting time stamps. The default is 'unknown', which means to use whatever the system environment specifies as the time zone. See Section 8.5 for more information.
+Sets the time zone for displaying and interpreting time stamps. The default is unknown, which means to use whatever the system environment specifies as the time zone. See Section 8.5.3 for more information.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-The shell command to execute to archive a completed segment of the WAL file series. If this is an empty string (the default), WAL archiving is disabled. Any %p in the string is replaced by the path name of the file to archive, and any %f is replaced by the file name only. (The path name is relative to the working directory of the server, i.e., the cluster's data directory.) Use %% to embed an actual % character in the command. For more information see Section 23.3.1. This parameter can only be set in the postgresql.conf file or on the server command line. It is important for the command to return a zero exit status if and only if it succeeds. Examples: archive_command = 'cp "%p" /mnt/server/archivedir/"%f"' archive_command = 'copy "%p" /mnt/server/archivedir/"%f"' # Windows
+The shell command to execute to archive a completed segment of the WAL file series. Any %p in the string is replaced by the path name of the file to archive, and any %f is replaced by the file name only. (The path name is relative to the working directory of the server, i.e., the cluster's data directory.) Use %% to embed an actual % character in the command. For more information see Section 24.3.1. This parameter can only be set in the postgresql.conf file or on the server command line. It is ignored unless archive_mode was enabled at server start. If archive_command is an empty string (the default) while archive_mode is enabled, then WAL archiving is temporarily disabled, but the server continues to accumulate WAL segment files in the expectation that a command will soon be provided. It is important for the command to return a zero exit status if and only if it succeeds. Examples: archive_command = 'cp "%p" /mnt/server/archivedir/"%f"' archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"' # Windows

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+When archive_mode is enabled, completed WAL segments can be sent to archive storage by setting archive_command. archive_mode and archive_command are separate variables so that archive_command can be changed without leaving archiving mode. This parameter can only be set at server start.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Controls whether the server should run the autovacuum daemon. This is off by default. stats_start_collector and stats_row_level must also be turned on for autovacuum to work. This parameter can only be set in the postgresql.conf file or on the server command line.
+Controls whether the server should run the autovacuum launcher daemon. This is on by default; however, track_counts must also be turned on for autovacuum to work. This parameter can only be set in the postgresql.conf file or on the server command line. Note that even when this parameter is disabled, the system will launch autovacuum processes if necessary to prevent transaction ID wraparound. See Section 23.1.3 for more information.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Specifies the minimum number of inserted, updated or deleted tuples needed to trigger an ANALYZE in any one table. The default is 250 tuples. This parameter can only be set in the postgresql.conf file or on the server command line. This setting can be overridden for individual tables by entries in pg_autovacuum.
+Specifies the minimum number of inserted, updated or deleted tuples needed to trigger an ANALYZE in any one table. The default is 50 tuples. This parameter can only be set in the postgresql.conf file or on the server command line. This setting can be overridden for individual tables by entries in pg_autovacuum.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Specifies the maximum age (in transactions) that a table's pg_class.relfrozenxid field can attain before a VACUUM operation is forced to prevent transaction ID wraparound within the table. Note that the system will launch autovacuum processes to prevent wraparound even when autovacuum is otherwise disabled. The default is 200 million transactions. This parameter can only be set at server start, but the setting can be reduced for individual tables by entries in pg_autovacuum. For more information see Section 22.1.3.
+Specifies the maximum age (in transactions) that a table's pg_class.relfrozenxid field can attain before a VACUUM operation is forced to prevent transaction ID wraparound within the table. Note that the system will launch autovacuum processes to prevent wraparound even when autovacuum is otherwise disabled. The default is 200 million transactions. This parameter can only be set at server start, but the setting can be reduced for individual tables by entries in pg_autovacuum. For more information see Section 23.1.3.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Specifies the maximum number of autovacuum processes (other than the autovacuum launcher) which may be running at any one time. The default is three. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Specifies the delay between activity rounds for the autovacuum daemon. In each round the daemon examines one database and issues VACUUM and ANALYZE commands as needed for tables in that database. The delay is measured in seconds, and the default is one minute (1m). This parameter can only be set in the postgresql.conf file or on the server command line. Note that even when this parameter is disabled, the system will periodically launch autovacuum processes in order to prevent transaction ID wraparound. See Section 22.1.3 for more information.
+Specifies the minimum delay between autovacuum runs on any given database. In each round the daemon examines the database and issues VACUUM and ANALYZE commands as needed for tables in that database. The delay is measured in seconds, and the default is one minute (1m). This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Specifies the cost delay value that will be used in automatic VACUUM operations. If -1 is specified (which is the default), the regular vacuum_cost_delay value will be used. This parameter can only be set in the postgresql.conf file or on the server command line. This setting can be overridden for individual tables by entries in pg_autovacuum.
+Specifies the cost delay value that will be used in automatic VACUUM operations. If -1 is specified, the regular vacuum_cost_delay value will be used. The default value is 20 milliseconds. This parameter can only be set in the postgresql.conf file or on the server command line. This setting can be overridden for individual tables by entries in pg_autovacuum.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Specifies the cost limit value that will be used in automatic VACUUM operations. If -1 is specified (which is the default), the regular vacuum_cost_limit value will be used. This parameter can only be set in the postgresql.conf file or on the server command line. This setting can be overridden for individual tables by entries in pg_autovacuum.
+Specifies the cost limit value that will be used in automatic VACUUM operations. If -1 is specified (which is the default), the regular vacuum_cost_limit value will be used. Note that the value is distributed proportionally among the running autovacuum workers, if there is more than one, so that the sum of the limits of each worker never exceeds the limit on this variable. This parameter can only be set in the postgresql.conf file or on the server command line. This setting can be overridden for individual tables by entries in pg_autovacuum.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Specifies the minimum number of updated or deleted tuples needed to trigger a VACUUM in any one table. The default is 500 tuples. This parameter can only be set in the postgresql.conf file or on the server command line. This setting can be overridden for individual tables by entries in pg_autovacuum.
+Specifies the minimum number of updated or deleted tuples needed to trigger a VACUUM in any one table. The default is 50 tuples. This parameter can only be set in the postgresql.conf file or on the server command line. This setting can be overridden for individual tables by entries in pg_autovacuum.

--- 8.2
+++ 8.3
@@ -1,3 +0,0 @@
-
-
-In each round, no more than this many buffers will be written as a result of the scan of the entire buffer pool. (If this limit is reached, the scan stops, and resumes at the next buffer during the next round.) The default value is five buffers. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -1,3 +0,0 @@
-
-
-To reduce the amount of work that will be needed at checkpoint time, the background writer also does a circular scan through the entire buffer pool, writing buffers that are found to be dirty. In each round, it examines up to bgwriter_all_percent of the buffers for this purpose. The default value is 0.333 (0.333% of the total number of shared buffers). With the default bgwriter_delay setting, this will allow the entire shared buffer pool to be scanned about once per minute. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Specifies the delay between activity rounds for the background writer. In each round the writer issues writes for some number of dirty buffers (controllable by the following parameters). It then sleeps for bgwriter_delay milliseconds, and repeats. The default value is 200 milliseconds (200ms). Note that on many systems, the effective resolution of sleep delays is 10 milliseconds; setting bgwriter_delay to a value that is not a multiple of 10 may have the same results as setting it to the next higher multiple of 10. This parameter can only be set in the postgresql.conf file or on the server command line.
+Specifies the delay between activity rounds for the background writer. In each round the writer issues writes for some number of dirty buffers (controllable by the following parameters). It then sleeps for bgwriter_delay milliseconds, and repeats. The default value is 200 milliseconds (200ms). Note that on many systems, the effective resolution of sleep delays is 10 milliseconds; setting bgwriter_delay to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple of 10. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-In each round, no more than this many buffers will be written as a result of scanning soon-to-be-recycled buffers. The default value is five buffers. This parameter can only be set in the postgresql.conf file or on the server command line.
+In each round, no more than this many buffers will be written by the background writer. Setting this to zero disables background writing (except for checkpoint activity). The default value is 100 buffers. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+The number of dirty buffers written in each round is based on the number of new buffers that have been needed by server processes during recent rounds. The average recent need is multiplied by bgwriter_lru_multiplier to arrive at an estimate of the number of buffers that will be needed during the next round. Dirty buffers are written until there are that many clean, reusable buffers available. (However, no more than bgwriter_lru_maxpages buffers will be written per round.) Thus, a setting of 1.0 represents a "just in time" policy of writing exactly the number of buffers predicted to be needed. Larger values provide some cushion against spikes in demand, while smaller values intentionally leave writes to be done by server processes. The default is 2.0. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -1,3 +0,0 @@
-
-
-To reduce the probability that server processes will need to issue their own writes, the background writer tries to write buffers that are likely to be recycled soon. In each round, it examines up to bgwriter_lru_percent of the buffers that are nearest to being recycled, and writes any that are dirty. The default value is 1.0 (1% of the total number of shared buffers). This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Reports the size of a disk block. It is determined by the value of BLCKSZ when building the server. The default value is 8192 bytes. The meaning of some configuration variables (such as shared_buffers) is influenced by block_size. See Section 17.4 for information.
+Reports the size of a disk block. It is determined by the value of BLCKSZ when building the server. The default value is 8192 bytes. The meaning of some configuration variables (such as shared_buffers) is influenced by block_size. See Section 18.4 for information.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Specifies the target length of checkpoints, as a fraction of the checkpoint interval. The default is 0.5. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Maximum distance between automatic WAL checkpoints, in log file segments (each segment is normally 16 megabytes). The default is three segments. This parameter can only be set in the postgresql.conf file or on the server command line.
+Maximum number of log file segments between automatic WAL checkpoints (each segment is normally 16 megabytes). The default is three segments. Increasing this parameter can increase the amount of time needed for crash recovery. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Maximum time between automatic WAL checkpoints, in seconds. The default is five minutes (5min). This parameter can only be set in the postgresql.conf file or on the server command line.
+Maximum time between automatic WAL checkpoints, in seconds. The default is five minutes (5min). Increasing this parameter can increase the amount of time needed for crash recovery. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Enables or disables the query planner's use of table constraints to optimize queries. The default is off. When this parameter is on, the planner compares query conditions with table 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. This can improve performance when inheritance is used to build partitioned tables. Currently, constraint_exclusion is disabled by default because it risks incorrect results if query plans are cached — if a table constraint is changed or dropped, the previously generated plan might now be wrong, and there is no built-in mechanism to force re-planning. (This deficiency will probably be addressed in a future PostgreSQL release.) Another reason for keeping it off is that the constraint checks are relatively expensive, and in many circumstances will yield no savings. It is recommended to turn this on only if you are actually using partitioned tables designed to take advantage of the feature. Refer to Section 5.9 for more information on using constraint exclusion and partitioning.
+Enables or disables the query planner's use of table constraints to optimize queries. The default is off. When this parameter is on, the planner compares query conditions with table 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. This can improve performance when inheritance is used to build partitioned tables. Currently, constraint_exclusion is disabled by default because the constraint checks are relatively expensive, and in many circumstances will yield no savings. It is recommended to turn this on only if you are actually using partitioned tables designed to take advantage of the feature. Refer to Section 5.9 for more information on using constraint exclusion and partitioning.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-This is the amount of time, in milliseconds, to wait on a lock before checking to see if there is a deadlock condition. The check for deadlock is relatively slow, so the server doesn't run it every time it waits for a lock. We (optimistically?) assume that deadlocks are not common in production applications and just wait on the lock for a while before starting the check for a deadlock. Increasing this value reduces the amount of time wasted in needless deadlock checks, but slows down reporting of real deadlock errors. The default is one second (1s), which is probably about the smallest value you would want in practice. On a heavily loaded server you might want to raise it. Ideally the setting should exceed your typical transaction time, so as to improve the odds that a lock will be released before the waiter decides to check for deadlock.
+This is the amount of time, in milliseconds, to wait on a lock before checking to see if there is a deadlock condition. The check for deadlock is relatively slow, so the server doesn't run it every time it waits for a lock. We optimistically assume that deadlocks are not common in production applications and just wait on the lock for a while before starting the check for a deadlock. Increasing this value reduces the amount of time wasted in needless deadlock checks, but slows down reporting of real deadlock errors. The default is one second (1s), which is probably about the smallest value you would want in practice. On a heavily loaded server you might want to raise it. Ideally the setting should exceed your typical transaction time, so as to improve the odds that a lock will be released before the waiter decides to check for deadlock. When log_lock_waits is set, this parameter also determines the length of time to wait before a log message is issued about the lock wait. If you are trying to investigate locking delays you might want to set a shorter than normal deadlock_timeout.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Sets the default statistics target for table columns that have not had a column-specific target set via ALTER TABLE SET STATISTICS. Larger values increase the time needed to do ANALYZE, but may improve the quality of the planner's estimates. The default is 10. For more information on the use of statistics by the PostgreSQL query planner, refer to Section 13.2.
+Sets the default statistics target for table columns that have not had a column-specific target set via ALTER TABLE SET STATISTICS. Larger values increase the time needed to do ANALYZE, but might improve the quality of the planner's estimates. The default is 10. For more information on the use of statistics by the PostgreSQL query planner, refer to Section 14.2.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-This variable specifies the default tablespace in which to create objects (tables and indexes) when a CREATE command does not explicitly specify a tablespace. The value is either the name of a tablespace, or an empty string to specify using the default tablespace of the current database. If the value does not match the name of any existing tablespace, PostgreSQL will automatically use the default tablespace of the current database. For more information on tablespaces, see Section 19.6.
+This variable specifies the default tablespace in which to create objects (tables and indexes) when a CREATE command does not explicitly specify a tablespace. The value is either the name of a tablespace, or an empty string to specify using the default tablespace of the current database. If the value does not match the name of any existing tablespace, PostgreSQL will automatically use the default tablespace of the current database. If a nondefault tablespace is specified, the user must have CREATE privilege for it, or creation attempts will fail. This variable is not used for temporary tables; for them, temp_tablespaces is consulted instead. For more information on tablespaces, see Section 20.6.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Selects the text search configuration that is used by those variants of the text search functions that do not have an explicit argument specifying the configuration. See Chapter 12 for further information. The built-in default is pg_catalog.simple, but initdb will initialize the configuration file with a setting that corresponds to the chosen lc_ctype locale, if a configuration matching that locale can be identified.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Each SQL transaction has an isolation level, which can be either "read uncommitted", "read committed", "repeatable read", or "serializable". This parameter controls the default isolation level of each new transaction. The default is "read committed". Consult Chapter 12 and SET TRANSACTION for more information.
+Each SQL transaction has an isolation level, which can be either "read uncommitted", "read committed", "repeatable read", or "serializable". This parameter controls the default isolation level of each new transaction. The default is "read committed". Consult Chapter 13 and SET TRANSACTION for more information.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-The planner will merge sub-queries into upper queries if the resulting FROM list would have no more than this many items. Smaller values reduce planning time but may yield inferior query plans. The default is eight. It is usually wise to keep this less than geqo_threshold. For more information see Section 13.3.
+The planner will merge sub-queries into upper queries if the resulting FROM list would have no more than this many items. Smaller values reduce planning time but might yield inferior query plans. The default is eight. It is usually wise to keep this less than geqo_threshold. For more information see Section 14.3.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-If this parameter is on, the PostgreSQL server will try to make sure that updates are physically written to disk, by issuing fsync() system calls or various equivalent methods (see wal_sync_method). This ensures that the database cluster can recover to a consistent state after an operating system or hardware crash. However, using fsync results in a performance penalty: when a transaction is committed, PostgreSQL must wait for the operating system to flush the write-ahead log to disk. When fsync is disabled, the operating system is allowed to do its best in buffering, ordering, and delaying writes. This can result in significantly improved performance. However, if the system crashes, the results of the last few committed transactions may be lost in part or whole. In the worst case, unrecoverable data corruption may occur. (Crashes of the database software itself are not a risk factor here. Only an operating-system-level crash creates a risk of corruption.) Due to the risks involved, there is no universally correct setting for fsync. Some administrators always disable fsync, while others only turn it off during initial bulk data loads, where there is a clear restart point if something goes wrong. Others always leave fsync enabled. The default is to enable fsync, for maximum reliability. If you trust your operating system, your hardware, and your utility company (or your battery backup), you can consider disabling fsync. This parameter can only be set in the postgresql.conf file or on the server command line. If you turn this parameter off, also consider turning off full_page_writes.
+If this parameter is on, the PostgreSQL server will try to make sure that updates are physically written to disk, by issuing fsync() system calls or various equivalent methods (see wal_sync_method). This ensures that the database cluster can recover to a consistent state after an operating system or hardware crash. However, using fsync results in a performance penalty: when a transaction is committed, PostgreSQL must wait for the operating system to flush the write-ahead log to disk. When fsync is disabled, the operating system is allowed to do its best in buffering, ordering, and delaying writes. This can result in significantly improved performance. However, if the system crashes, the results of the last few committed transactions might be lost in part or whole. In the worst case, unrecoverable data corruption might occur. (Crashes of the database software itself are not a risk factor here. Only an operating-system-level crash creates a risk of corruption.) Due to the risks involved, there is no universally correct setting for fsync. Some administrators always disable fsync, while others only turn it off during initial bulk data loads, where there is a clear restart point if something goes wrong. Others always leave fsync enabled. The default is to enable fsync, for maximum reliability. If you trust your operating system, your hardware, and your utility company (or your battery backup), you can consider disabling fsync. In many situations, turning off synchronous_commit for noncritical transactions can provide much of the potential performance benefit of turning off fsync, without the attendant risks of data corruption. This parameter can only be set in the postgresql.conf file or on the server command line. If you turn this parameter off, also consider turning off full_page_writes.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-When this parameter is on, the PostgreSQL server writes the entire content of each disk page to WAL during the first modification of that page after a checkpoint. This is needed because a page write that is in process during an operating system crash might be only partially completed, leading to an on-disk page that contains a mix of old and new data. The row-level change data normally stored in WAL will not be enough to completely restore such a page during post-crash recovery. Storing the full page image guarantees that the page can be correctly restored, but at a price in increasing the amount of data that must be written to WAL. (Because WAL replay always starts from a checkpoint, it is sufficient to do this during the first change of each page after a checkpoint. Therefore, one way to reduce the cost of full-page writes is to increase the checkpoint interval parameters.) Turning this parameter off speeds normal operation, but might lead to a corrupt database after an operating system crash or power failure. The risks are similar to turning off fsync, though smaller. It may be safe to turn off this parameter if you have hardware (such as a battery-backed disk controller) or file-system software that reduces the risk of partial page writes to an acceptably low level (e.g., ReiserFS 4). Turning off this parameter does not affect use of WAL archiving for point-in-time recovery (PITR) (see Section 23.3). This parameter can only be set in the postgresql.conf file or on the server command line. The default is on.
+When this parameter is on, the PostgreSQL server writes the entire content of each disk page to WAL during the first modification of that page after a checkpoint. This is needed because a page write that is in process during an operating system crash might be only partially completed, leading to an on-disk page that contains a mix of old and new data. The row-level change data normally stored in WAL will not be enough to completely restore such a page during post-crash recovery. Storing the full page image guarantees that the page can be correctly restored, but at a price in increasing the amount of data that must be written to WAL. (Because WAL replay always starts from a checkpoint, it is sufficient to do this during the first change of each page after a checkpoint. Therefore, one way to reduce the cost of full-page writes is to increase the checkpoint interval parameters.) Turning this parameter off speeds normal operation, but might lead to a corrupt database after an operating system crash or power failure. The risks are similar to turning off fsync, though smaller. It might be safe to turn off this parameter if you have hardware (such as a battery-backed disk controller) or file-system software that reduces the risk of partial page writes to an acceptably low level (e.g., ReiserFS 4). Turning off this parameter does not affect use of WAL archiving for point-in-time recovery (PITR) (see Section 24.3). This parameter can only be set in the postgresql.conf file or on the server command line. The default is on.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Soft upper limit of the size of the set returned by GIN index. For more information see Section 51.4.
+Soft upper limit of the size of the set returned by GIN index. For more information see Section 52.4.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-The planner will rewrite explicit JOIN constructs (except FULL JOINs) into lists of FROM items whenever a list of no more than this many items would result. Smaller values reduce planning time but may yield inferior query plans. By default, this variable is set the same as from_collapse_limit, which is appropriate for most uses. Setting it to 1 prevents any reordering of explicit JOINs. Thus, the explicit join order specified in the query will be the actual order in which the relations are joined. The query planner does not always choose the optimal join order; advanced users may elect to temporarily set this variable to 1, and then specify the join order they desire explicitly. For more information see Section 13.3.
+The planner will rewrite explicit JOIN constructs (except FULL JOINs) into lists of FROM items whenever a list of no more than this many items would result. Smaller values reduce planning time but might yield inferior query plans. By default, this variable is set the same as from_collapse_limit, which is appropriate for most uses. Setting it to 1 prevents any reordering of explicit JOINs. Thus, the explicit join order specified in the query will be the actual order in which the relations are joined. The query planner does not always choose the optimal join order; advanced users can elect to temporarily set this variable to 1, and then specify the join order they desire explicitly. For more information see Section 14.3.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Sets whether Kerberos user names should be treated case-insensitively. The default is off (case sensitive). This parameter can only be set at server start.
+Sets whether Kerberos and GSSAPI user names should be treated case-insensitively. The default is off (case sensitive). This parameter can only be set at server start.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Sets the realm to match Kerberos, GSSAPI and SSPI user names against. See Section 21.2.5, Section 21.2.3 or Section 21.2.4 for details. This parameter can only be set at server start.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Sets the host name part of the service principal. This, combined with krb_srvname, is used to generate the complete service principal, that is krb_srvname/krb_server_hostname@REALM. If not set, the default is the server host name. See Section 20.2.3 for details. This parameter can only be set at server start.
+Sets the host name part of the service principal. This, combined with krb_srvname, is used to generate the complete service principal, that is krb_srvname/krb_server_hostname@REALM. If not set, the default is the server host name. See Section 21.2.5 for details. This parameter can only be set at server start.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Sets the location of the Kerberos server key file. See Section 20.2.3 for details. This parameter can only be set at server start.
+Sets the location of the Kerberos server key file. See Section 21.2.5 or Section 21.2.3 for details. This parameter can only be set at server start.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Sets the Kerberos service name. See Section 20.2.3 for details. This parameter can only be set at server start.
+Sets the Kerberos service name. See Section 21.2.5 for details. This parameter can only be set at server start.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Reports the locale in which sorting of textual data is done. See Section 21.1 for more information. The value is determined when the database cluster is initialized.
+Reports the locale in which sorting of textual data is done. See Section 22.1 for more information. The value is determined when the database cluster is initialized.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Reports the locale that determines character classifications. See Section 21.1 for more information. The value is determined when the database cluster is initialized. Ordinarily this will be the same as lc_collate, but for special applications it might be set differently.
+Reports the locale that determines character classifications. See Section 22.1 for more information. The value is determined when the database cluster is initialized. Ordinarily this will be the same as lc_collate, but for special applications it might be set differently.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Sets the language in which messages are displayed. Acceptable values are system-dependent; see Section 21.1 for more information. If this variable is set to the empty string (which is the default) then the value is inherited from the execution environment of the server in a system-dependent way. On some systems, this locale category does not exist. Setting this variable will still work, but there will be no effect. Also, there is a chance that no translated messages for the desired language exist. In that case you will continue to see the English messages. Only superusers can change this setting, because it affects the messages sent to the server log as well as to the client.
+Sets the language in which messages are displayed. Acceptable values are system-dependent; see Section 22.1 for more information. If this variable is set to the empty string (which is the default) then the value is inherited from the execution environment of the server in a system-dependent way. On some systems, this locale category does not exist. Setting this variable will still work, but there will be no effect. Also, there is a chance that no translated messages for the desired language exist. In that case you will continue to see the English messages. Only superusers can change this setting, because it affects the messages sent to the server log as well as to the client.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Sets the locale to use for formatting monetary amounts, for example with the to_char family of functions. Acceptable values are system-dependent; see Section 21.1 for more information. If this variable is set to the empty string (which is the default) then the value is inherited from the execution environment of the server in a system-dependent way.
+Sets the locale to use for formatting monetary amounts, for example with the to_char family of functions. Acceptable values are system-dependent; see Section 22.1 for more information. If this variable is set to the empty string (which is the default) then the value is inherited from the execution environment of the server in a system-dependent way.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Sets the locale to use for formatting numbers, for example with the to_char family of functions. Acceptable values are system-dependent; see Section 21.1 for more information. If this variable is set to the empty string (which is the default) then the value is inherited from the execution environment of the server in a system-dependent way.
+Sets the locale to use for formatting numbers, for example with the to_char family of functions. Acceptable values are system-dependent; see Section 22.1 for more information. If this variable is set to the empty string (which is the default) then the value is inherited from the execution environment of the server in a system-dependent way.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Sets the locale to use for formatting date and time values. (Currently, this setting does nothing, but it may in the future.) Acceptable values are system-dependent; see Section 21.1 for more information. If this variable is set to the empty string (which is the default) then the value is inherited from the execution environment of the server in a system-dependent way.
+Sets the locale to use for formatting date and time values. (Currently, this setting does nothing, but it might in the future.) Acceptable values are system-dependent; see Section 22.1 for more information. If this variable is set to the empty string (which is the default) then the value is inherited from the execution environment of the server in a system-dependent way.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+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. Enabling this parameter can be helpful in tracking autovacuum activity. This setting can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Causes checkpoints to be logged in the server log. Some statistics about each checkpoint are included in the log messages, including the number of buffers written and the time spent writing them. This parameter can only be set in the postgresql.conf file or on the server command line. The default is off.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-This outputs a line to the server log detailing each successful connection. This is off by default, although it is probably very useful. Some client programs, like psql, attempt to connect twice while determining if a password is required, so duplicate "connection received" messages do not necessarily indicate a problem. This parameter can only be set in the postgresql.conf file or on the server command line.
+Causes each attempted connection to the server to be logged, as well as successful completion of client authentication. This parameter can only be set in the postgresql.conf file or on the server command line. The default is off. Note: Some client programs, like psql, attempt to connect twice while determining if a password is required, so duplicate "connection received" messages do not necessarily indicate a problem.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-PostgreSQL supports several methods for logging server messages, including stderr and syslog. On Windows, eventlog is also supported. Set this parameter to a list of desired log destinations separated by commas. The default is to log to stderr only. This parameter can only be set in the postgresql.conf file or on the server command line.
+PostgreSQL supports several methods for logging server messages, including stderr, csvlog and syslog. On Windows, eventlog is also supported. Set this parameter to a list of desired log destinations separated by commas. The default is to log to stderr only. This parameter can only be set in the postgresql.conf file or on the server command line. If csvlog is included in log_destination, log entries are output in "comma separated value" format, which is convenient for loading them into programs. See Section 18.7.4 for details. logging_collector must be enabled to generate CSV-format log output. Note: On most Unix systems, you will need to alter the configuration of your system's syslog daemon in order to make use of the syslog option for log_destination. PostgreSQL can log to syslog facilities LOCAL0 through LOCAL7 (see syslog_facility), but the default syslog configuration on most platforms will discard all such messages. You will need to add something like local0.* /var/log/postgresql to the syslog daemon's configuration file to make it work.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-When redirect_stderr is enabled, this parameter determines the directory in which log files will be created. It may be specified as an absolute path, or relative to the cluster data directory. This parameter can only be set in the postgresql.conf file or on the server command line.
+When logging_collector is enabled, this parameter determines the directory in which log files will be created. It can be specified as an absolute path, or relative to the cluster data directory. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-When redirect_stderr is enabled, this parameter sets the file names of the created log files. The value is treated as a strftime pattern, so %-escapes can be used to specify time-varying file names. If no %-escapes are present, PostgreSQL will append the epoch of the new log file's open time. For example, if log_filename were server_log, then the chosen file name would be server_log.1093827753 for a log starting at Sun Aug 29 19:02:33 2004 MST. This parameter can only be set in the postgresql.conf file or on the server command line.
+When logging_collector is enabled, this parameter sets the file names of the created log files. The value is treated as a strftime pattern, so %-escapes can be used to specify time-varying file names. (Note that if there are any time-zone-dependent %-escapes, the computation is done in the zone specified by log_timezone.) If no %-escapes are present, PostgreSQL will append the epoch of the new log file's creation time. For example, if log_filename were server_log, then the chosen file name would be server_log.1093827753 for a log starting at Sun Aug 29 19:02:33 2004 MST. This parameter can only be set in the postgresql.conf file or on the server command line. If CSV-format output is enabled in log_destination, .csv will be appended to the timestamped log file name to create the file name for CSV-format output. (If log_filename ends in .log, the suffix is replaced instead.) In the case of the example above, the CSV file name will be server_log.1093827753.csv.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-This is a printf-style string that is output at the beginning of each log line. The default is an empty string. Each recognized escape is replaced as outlined below - anything else that looks like an escape is ignored. Other characters are copied straight to the log line. Some escapes are only recognized by session processes, and do not apply to background processes such as the main server process. Syslog produces its own time stamp and process ID information, so you probably do not want to use those escapes if you are using syslog. This parameter can only be set in the postgresql.conf file or on the server command line. Escape Effect Session only %u User name yes %d Database name yes %r Remote host name or IP address, and remote port yes %h Remote host name or IP address yes %p Process ID no %t Time stamp (no milliseconds, no timezone on Windows) no %m Time stamp with milliseconds no %i Command tag: This is the command that generated the log line. yes %c Session ID: A unique identifier for each session. It is 2 4-byte hexadecimal numbers (without leading zeros) separated by a dot. The numbers are the session start time and the process ID, so this can also be used as a space saving way of printing these items. yes %l Number of the log line for each process, starting at 1 no %s Session start time stamp yes %x Transaction ID yes %q Does not produce any output, but tells non-session processes to stop at this point in the string. Ignored by session processes. no %% Literal % no
+This is a printf-style string that is output at the beginning of each log line. % characters begin "escape sequences" that are replaced with status information as outlined below. Unrecognized escapes are ignored. Other characters are copied straight to the log line. Some escapes are only recognized by session processes, and do not apply to background processes such as the main server process. This parameter can only be set in the postgresql.conf file or on the server command line. The default is an empty string. Escape Effect Session only %u User name yes %d Database name yes %r Remote host name or IP address, and remote port yes %h Remote host name or IP address yes %p Process ID no %t Time stamp without milliseconds no %m Time stamp with milliseconds no %i Command tag: type of session's current command yes %c Session ID: see below no %l Number of the log line for each session or process, starting at 1 no %s Process start time stamp no %v Virtual transaction ID (backendID/localXID) no %x Transaction ID (0 if none is assigned) no %q Produces no output, but tells non-session processes to stop at this point in the string; ignored by session processes no %% Literal % no The %c escape prints a quasi-unique session identifier, consisting of two 4-byte hexadecimal numbers (without leading zeros) separated by a dot. The numbers are the process start time and the process ID, so %c can also be used as a space saving way of printing those items. Tip: If you set a nonempty value for log_line_prefix, you should usually make its last character be a space, to provide visual separation from the rest of the log line. A punctuation character could be used too. Tip: Syslog produces its own time stamp and process ID information, so you probably do not want to use those escapes if you are logging to syslog.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Controls whether a log message is produced when a session waits longer than deadlock_timeout to acquire a lock. This is useful in determining if lock waits are causing poor performance. The default is off.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Controls whether or not the SQL statement that causes an error condition will be recorded in the server log. The current SQL statement is included in the log entry for any message of the specified severity or higher. Valid values are DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, FATAL, and PANIC. The default is ERROR, which means statements causing errors, fatal errors, or panics will be logged. To effectively turn off logging of failing statements, set this parameter to PANIC. Only superusers can change this setting.
+Controls whether or not the SQL statement that causes an error condition will be recorded in the server log. The current SQL statement is included in the log entry for any message of the specified severity or higher. Valid values are DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL, and PANIC. The default is ERROR, which means statements causing errors, log messages, fatal errors, or panics will be logged. To effectively turn off logging of failing statements, set this parameter to PANIC. Only superusers can change this setting.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-When redirect_stderr is enabled, this parameter determines the maximum lifetime of an individual log file. After this many minutes have elapsed, a new log file will be created. Set to zero to disable time-based creation of new log files. This parameter can only be set in the postgresql.conf file or on the server command line.
+When logging_collector is enabled, this parameter determines the maximum lifetime of an individual log file. After this many minutes have elapsed, a new log file will be created. Set to zero to disable time-based creation of new log files. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-When redirect_stderr is enabled, this parameter determines the maximum size of an individual log file. After this many kilobytes have been emitted into a log file, a new log file will be created. Set to zero to disable size-based creation of new log files. This parameter can only be set in the postgresql.conf file or on the server command line.
+When logging_collector is enabled, this parameter determines the maximum size of an individual log file. After this many kilobytes have been emitted into a log file, a new log file will be created. Set to zero to disable size-based creation of new log files. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Controls whether temporary files are logged when deleted. Temporary files can be created for sorts, hashes, and temporary query results. A value of zero logs all temporary files, and positive values log only files whose size is equal or greater than the specified number of kilobytes. The default is -1, which disables this logging.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Sets the time zone used for timestamps written in the log. Unlike timezone, this value is cluster-wide, so that all sessions will report timestamps consistently. The default is unknown, which means to use whatever the system environment specifies as the time zone. See Section 8.5.3 for more information. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-When redirect_stderr is enabled, this parameter will cause PostgreSQL to truncate (overwrite), rather than append to, any existing log file of the same name. However, truncation will occur only when a new file is being opened due to time-based rotation, not during server startup or size-based rotation. When off, pre-existing files will be appended to in all cases. For example, using this setting in combination with a log_filename like postgresql-%H.log would result in generating twenty-four hourly log files and then cyclically overwriting them. This parameter can only be set in the postgresql.conf file or on the server command line. Example: To keep 7 days of logs, one log file per day named server_log.Mon, server_log.Tue, etc, and automatically overwrite last week's log with this week's log, set log_filename to server_log.%a, log_truncate_on_rotation to on, and log_rotation_age to 1440. Example: To keep 24 hours of logs, one log file per hour, but also rotate sooner if the log file size exceeds 1GB, set log_filename to server_log.%H%M, log_truncate_on_rotation to on, log_rotation_age to 60, and log_rotation_size to 1000000. Including %M in log_filename allows any size-driven rotations that may occur to select a file name different from the hour's initial file name.
+When logging_collector is enabled, this parameter will cause PostgreSQL to truncate (overwrite), rather than append to, any existing log file of the same name. However, truncation will occur only when a new file is being opened due to time-based rotation, not during server startup or size-based rotation. When off, pre-existing files will be appended to in all cases. For example, using this setting in combination with a log_filename like postgresql-%H.log would result in generating twenty-four hourly log files and then cyclically overwriting them. This parameter can only be set in the postgresql.conf file or on the server command line. Example: To keep 7 days of logs, one log file per day named server_log.Mon, server_log.Tue, etc, and automatically overwrite last week's log with this week's log, set log_filename to server_log.%a, log_truncate_on_rotation to on, and log_rotation_age to 1440. Example: To keep 24 hours of logs, one log file per hour, but also rotate sooner if the log file size exceeds 1GB, set log_filename to server_log.%H%M, log_truncate_on_rotation to on, log_rotation_age to 60, and log_rotation_size to 1000000. Including %M in log_filename allows any size-driven rotations that might occur to select a file name different from the hour's initial file name.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+This parameter allows messages sent to stderr, and CSV-format log output, to be captured and redirected into log files. This approach is often more useful than logging to syslog, since some types of messages might not appear in syslog output (a common example is dynamic-linker failure messages). This parameter can only be set at server start.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Specifies the maximum amount of memory to be used in maintenance operations, such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. It defaults to 16 megabytes (16MB). Since only one of these operations can be executed at a time by a database session, and an installation normally doesn't have many of them running concurrently, it's safe to set this value significantly larger than work_mem. Larger settings may improve performance for vacuuming and for restoring database dumps.
+Specifies the maximum amount of memory to be used in maintenance operations, such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. It defaults to 16 megabytes (16MB). Since only one of these operations can be executed at a time by a database session, and an installation normally doesn't have many of them running concurrently, it's safe to set this value significantly larger than work_mem. Larger settings might improve performance for vacuuming and for restoring database dumps. Note that when autovacuum runs, up to autovacuum_max_workers times this memory may be allocated, so be careful not to set the default value too high.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Determines the maximum number of concurrent connections to the database server. The default is typically 100 connections, but may be less if your kernel settings will not support it (as determined during initdb). This parameter can only be set at server start. Increasing this parameter may cause PostgreSQL to request more System V shared memory or semaphores than your operating system's default configuration allows. See Section 16.4.1 for information on how to adjust those parameters, if necessary.
+Determines the maximum number of concurrent connections to the database server. The default is typically 100 connections, but might be less if your kernel settings will not support it (as determined during initdb). This parameter can only be set at server start. Increasing this parameter might cause PostgreSQL to request more System V shared memory or semaphores than your operating system's default configuration allows. See Section 17.4.1 for information on how to adjust those parameters, if necessary.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-The shared lock table is created to track locks on max_locks_per_transaction * (max_connections + max_prepared_transactions) objects (e.g. tables); hence, no more than this many distinct objects can be locked at any one time. This parameter controls the average number of object locks allocated for each transaction; individual transactions can lock more objects as long as the locks of all transactions fit in the lock table. This is not the number of rows that can be locked; that value is unlimited. The default, 64, has historically proven sufficient, but you might need to raise this value if you have clients that touch many different tables in a single transaction. This parameter can only be set at server start. Increasing this parameter may cause PostgreSQL to request more System V shared memory than your operating system's default configuration allows. See Section 16.4.1 for information on how to adjust those parameters, if necessary.
+The shared lock table is created to track locks on max_locks_per_transaction * (max_connections + max_prepared_transactions) objects (e.g. tables); hence, no more than this many distinct objects can be locked at any one time. This parameter controls the average number of object locks allocated for each transaction; individual transactions can lock more objects as long as the locks of all transactions fit in the lock table. This is not the number of rows that can be locked; that value is unlimited. The default, 64, has historically proven sufficient, but you might need to raise this value if you have clients that touch many different tables in a single transaction. This parameter can only be set at server start. Increasing this parameter might cause PostgreSQL to request more System V shared memory than your operating system's default configuration allows. See Section 17.4.1 for information on how to adjust those parameters, if necessary.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Sets the maximum number of transactions that can be in the "prepared" state simultaneously (see PREPARE TRANSACTION). Setting this parameter to zero disables the prepared-transaction feature. The default is five transactions. This parameter can only be set at server start. If you are not using prepared transactions, this parameter may as well be set to zero. If you are using them, you will probably want max_prepared_transactions to be at least as large as max_connections, to avoid unwanted failures at the prepare step. Increasing this parameter may cause PostgreSQL to request more System V shared memory than your operating system's default configuration allows. See Section 16.4.1 for information on how to adjust those parameters, if necessary.
+Sets the maximum number of transactions that can be in the "prepared" state simultaneously (see PREPARE TRANSACTION). Setting this parameter to zero disables the prepared-transaction feature. The default is five transactions. This parameter can only be set at server start. If you are not using prepared transactions, this parameter may as well be set to zero. If you are using them, you will probably want max_prepared_transactions to be at least as large as max_connections, to avoid unwanted failures at the prepare step. Increasing this parameter might cause PostgreSQL to request more System V shared memory than your operating system's default configuration allows. See Section 17.4.1 for information on how to adjust those parameters, if necessary.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Specifies the maximum safe depth of the server's execution stack. The ideal setting for this parameter is the actual stack size limit enforced by the kernel (as set by ulimit -s or local equivalent), less a safety margin of a megabyte or so. The safety margin is needed because the stack depth is not checked in every routine in the server, but only in key potentially-recursive routines such as expression evaluation. The default setting is two megabytes (2MB), which is conservatively small and unlikely to risk crashes. However, it may be too small to allow execution of complex functions. Only superusers can change this setting. Setting max_stack_depth higher than the actual kernel limit will mean that a runaway recursive function can crash an individual backend process. On platforms where PostgreSQL can determine the kernel limit, it will not let you set this variable to an unsafe value. However, not all platforms provide the information, so caution is recommended in selecting a value.
+Specifies the maximum safe depth of the server's execution stack. The ideal setting for this parameter is the actual stack size limit enforced by the kernel (as set by ulimit -s or local equivalent), less a safety margin of a megabyte or so. The safety margin is needed because the stack depth is not checked in every routine in the server, but only in key potentially-recursive routines such as expression evaluation. The default setting is two megabytes (2MB), which is conservatively small and unlikely to risk crashes. However, it might be too small to allow execution of complex functions. Only superusers can change this setting. Setting max_stack_depth higher than the actual kernel limit will mean that a runaway recursive function can crash an individual backend process. On platforms where PostgreSQL can determine the kernel limit, it will not let you set this variable to an unsafe value. However, not all platforms provide the information, so caution is recommended in selecting a value.

--- 8.2
+++ 8.3
@@ -1,3 +0,0 @@
-
-
-This parameter allows messages sent to stderr to be captured and redirected into log files. This method, in combination with logging to stderr, is often more useful than logging to syslog, since some types of messages may not appear in syslog output (a common example is dynamic-linker failure messages). This parameter can only be set at server start.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-The regular expression "flavor" can be set to advanced, extended, or basic. The default is advanced. The extended setting may be useful for exact backwards compatibility with pre-7.4 releases of PostgreSQL. See Section 9.7.3.1 for details.
+The regular expression "flavor" can be set to advanced, extended, or basic. The default is advanced. The extended setting might be useful for exact backwards compatibility with pre-7.4 releases of PostgreSQL. See Section 9.7.3.1 for details.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+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.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Sets the amount of memory the database server uses for shared memory buffers. The default is typically 32 megabytes (32MB), but may be less if your kernel settings will not support it (as determined during initdb). This setting must be at least 128 kilobytes and at least 16 kilobytes times max_connections. (Non-default values of BLCKSZ change the minimum.) However, settings significantly higher than the minimum are usually needed for good performance. Several tens of megabytes are recommended for production installations. This parameter can only be set at server start. Increasing this parameter may cause PostgreSQL to request more System V shared memory than your operating system's default configuration allows. See Section 16.4.1 for information on how to adjust those parameters, if necessary.
+Sets the amount of memory the database server uses for shared memory buffers. The default is typically 32 megabytes (32MB), but might be less if your kernel settings will not support it (as determined during initdb). This setting must be at least 128 kilobytes and at least 16 kilobytes times max_connections. (Non-default values of BLCKSZ change the minimum.) However, settings significantly higher than the minimum are usually needed for good performance. This parameter can only be set at server start. If you have a dedicated database server with 1GB or more of RAM, a reasonable starting value for shared_buffers is 25% of the memory in your system. There are some workloads where even large settings for shared_buffers are effective, but because PostgreSQL also relies on the operating system cache, it is unlikely that an allocation of more than 40% of RAM to shared_buffers will work better than a smaller amount. Larger settings for shared_buffers usually require a corresponding increase in checkpoint_segments, in order to spread out the process of writing large quantities of new or changed data over a longer period of time. On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate, so as to leave adequate space for the operating system. Also, on Windows, large values for shared_buffers aren't as effective. You may find better results keeping the setting relatively low and using the operating system cache more instead. The useful range for shared_buffers on Windows systems is generally from 64MB to 512MB. Increasing this parameter might cause PostgreSQL to request more System V shared memory than your operating system's default configuration allows. See Section 17.4.1 for information on how to adjust those parameters, if necessary.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-This variable specifies one or more shared libraries that are to be preloaded at server start. If more than one library is to be loaded, separate their names with commas. For example, '$libdir/mylib' would cause mylib.so (or on some platforms, mylib.sl) to be preloaded from the installation's standard library directory. This parameter can only be set at server start. PostgreSQL procedural language libraries can be preloaded in this way, typically by using the syntax '$libdir/plXXX' where XXX is pgsql, perl, tcl, or python. By preloading a shared library, the library startup time is avoided when the library is first used. However, the time to start each new server process may increase slightly, even if that process never uses the library. So this parameter is recommended only for libraries that will be used in most sessions. Note: On Windows hosts, preloading a library at server start will not reduce the time required to start each new server process; each server process will re-load all preload libraries. However, shared_preload_libraries is still useful on Windows hosts because some shared libraries may need to perform certain operations that only take place at postmaster start (for example, a shared library may need to reserve lightweight locks or shared memory and you can't do that after the postmaster has started). If a specified library is not found, the server will fail to start. Every PostgreSQL-supported library has a "magic block" that is checked to guarantee compatibility. For this reason, non-PostgreSQL libraries cannot be loaded in this way.
+This variable specifies one or more shared libraries that are to be preloaded at server start. If more than one library is to be loaded, separate their names with commas. For example, '$libdir/mylib' would cause mylib.so (or on some platforms, mylib.sl) to be preloaded from the installation's standard library directory. This parameter can only be set at server start. PostgreSQL procedural language libraries can be preloaded in this way, typically by using the syntax '$libdir/plXXX' where XXX is pgsql, perl, tcl, or python. By preloading a shared library, the library startup time is avoided when the library is first used. However, the time to start each new server process might increase slightly, even if that process never uses the library. So this parameter is recommended only for libraries that will be used in most sessions. Note: On Windows hosts, preloading a library at server start will not reduce the time required to start each new server process; each server process will re-load all preload libraries. However, shared_preload_libraries is still useful on Windows hosts because some shared libraries may need to perform certain operations that only take place at postmaster start (for example, a shared library may need to reserve lightweight locks or shared memory and you can't do that after the postmaster has started). If a specified library is not found, the server will fail to start. Every PostgreSQL-supported library has a "magic block" that is checked to guarantee compatibility. For this reason, non-PostgreSQL libraries cannot be loaded in this way.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Runs the server silently. If this parameter is set, the server will automatically run in background and any controlling terminals are disassociated. The server's standard output and standard error are redirected to /dev/null, so any messages sent to them will be lost. Unless syslog logging is selected or redirect_stderr is enabled, using this parameter is discouraged because it makes it impossible to see error messages. This parameter can only be set at server start.
+Runs the server silently. If this parameter is set, the server will automatically run in background and any controlling terminals are disassociated. The server's standard output and standard error are redirected to /dev/null, so any messages sent to them will be lost. Unless syslog logging is selected or logging_collector is enabled, using this parameter is discouraged because it makes it impossible to see error messages. This parameter can only be set at server start.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-This controls the inheritance semantics. If turned off, subtables are not included by various commands by default; basically an implied ONLY key word. This was added for compatibility with releases prior to 7.1. See Section 5.8 for more information.
+This setting controls whether undecorated table references are considered to include inheritance child tables. The default is on, which means child tables are included (thus, a * suffix is assumed by default). If turned off, child tables are not included (thus, an ONLY prefix is assumed). The SQL standard requires child tables to be included, so the off setting is not spec-compliant, but it is provided for compatibility with PostgreSQL releases prior to 7.1. See Section 5.8 for more information. Turning sql_inheritance off is deprecated, because that behavior has been found to be error-prone as well as contrary to SQL standard. Discussions of inheritance behavior elsewhere in this manual generally assume that it is on.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Enables SSL connections. Please read Section 16.7 before using this. The default is off. This parameter can only be set at server start.
+Enables SSL connections. Please read Section 17.8 before using this. The default is off. This parameter can only be set at server start.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Specifies a list of SSL ciphers that are allowed to be used on secure connections. See the openssl manual page for a list of supported ciphers. This parameter is unavailable unless the server is compiled with support for SSL.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-This controls whether ordinary string literals ('...') treat backslashes literally, as specified in the SQL standard. The default is currently off, causing PostgreSQL to have its historical behavior of treating backslashes as escape characters. The default will change to on in a future release to improve compatibility with the standard. Applications may check this parameter to determine how string literals will be processed. The presence of this parameter can also be taken as an indication that the escape string syntax (E'...') is supported. Escape string syntax should be used if an application desires backslashes to be treated as escape characters.
+This controls whether ordinary string literals ('...') treat backslashes literally, as specified in the SQL standard. The default is currently off, causing PostgreSQL to have its historical behavior of treating backslashes as escape characters. The default will change to on in a future release to improve compatibility with the standard. Applications can check this parameter to determine how string literals will be processed. The presence of this parameter can also be taken as an indication that the escape string syntax (E'...') is supported. Escape string syntax should be used if an application desires backslashes to be treated as escape characters.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Abort any statement that takes over the specified number of milliseconds, starting from the time the command arrives at the server from the client. If log_min_error_statement is set to ERROR or lower, the statement that timed out will also be logged. A value of zero (the default) turns off the limitation.
+Abort any statement that takes over the specified number of milliseconds, starting from the time the command arrives at the server from the client. If log_min_error_statement is set to ERROR or lower, the statement that timed out will also be logged. A value of zero (the default) turns off the limitation. Setting statement_timeout in postgresql.conf is not recommended because it affects all sessions.

--- 8.2
+++ 8.3
@@ -1,3 +0,0 @@
-
-
-Enables the collection of block-level statistics on database activity. This parameter is off by default. Only superusers can change this setting.

--- 8.2
+++ 8.3
@@ -1,3 +0,0 @@
-
-
-Enables the collection of information on the currently executing command of each session, along with the time at which that command began execution. This parameter is on by default. Note that even when enabled, this information is not visible to all users, only to superusers and the user owning the session being reported on; so it should not represent a security risk. Only superusers can change this setting.

--- 8.2
+++ 8.3
@@ -1,3 +0,0 @@
-
-
-If on, collected block-level and row-level statistics are zeroed out whenever the server is restarted. If off, statistics are accumulated across server restarts. This parameter is off by default. This parameter can only be set at server start.

--- 8.2
+++ 8.3
@@ -1,3 +0,0 @@
-
-
-Enables the collection of row-level statistics on database activity. This parameter is off by default. Only superusers can change this setting.

--- 8.2
+++ 8.3
@@ -1,3 +0,0 @@
-
-
-Controls whether the server should start the statistics-collection subprocess. This is on by default, but may be turned off if you know you have no interest in collecting statistics or running autovacuum. This parameter can only be set at server start, because the collection subprocess cannot be started or stopped on-the-fly. (However, the extent to which statistics are actually gathered can be changed while the server is running, so long as the subprocess exists.)

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+This allows sequential scans of large tables to synchronize with each other, so that concurrent scans read the same block at about the same time and hence share the I/O workload. When this is enabled, a scan might start in the middle of the table and then "wrap around" the end to cover all rows, so as to synchronize with the activity of scans already in progress. This can result in unpredictable changes in the row ordering returned by queries that have no ORDER BY clause. Setting this parameter to off ensures the pre-8.3 behavior in which a sequential scan always starts from the beginning of the table. The default is on.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Specifies whether transaction commit will wait for WAL records to be written to disk before the command returns a "success" indication to the client. The default, and safe, setting is on. When off, there can be a delay between when success is reported to the client and when the transaction is really guaranteed to be safe against a server crash. (The maximum delay is three times wal_writer_delay.) Unlike fsync, setting this parameter to off does not create any risk of database inconsistency: a crash might result in some recent allegedly-committed transactions being lost, but the database state will be just the same as if those transactions had been aborted cleanly. So, turning synchronous_commit off can be a useful alternative when performance is more important than exact certainty about the durability of a transaction. For more discussion see Section 28.3. This parameter can be changed at any time; the behavior for any one transaction is determined by the setting in effect when it commits. It is therefore possible, and useful, to have some transactions commit synchronously and others asynchronously. For example, to make a single multi-statement transaction commit asynchronously when the default is the opposite, issue SET LOCAL synchronous_commit TO OFF within the transaction.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-When logging to syslog is enabled, this parameter determines the syslog "facility" to be used. You may choose from LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7; the default is LOCAL0. See also the documentation of your system's syslog daemon. This parameter can only be set in the postgresql.conf file or on the server command line. This parameter is unavailable unless the server is compiled with support for syslog.
+When logging to syslog is enabled, this parameter determines the syslog "facility" to be used. You can choose from LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7; the default is LOCAL0. See also the documentation of your system's syslog daemon. This parameter can only be set in the postgresql.conf file or on the server command line. This parameter is unavailable unless the server is compiled with support for syslog.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-On systems that support the TCP_KEEPCNT socket option, specifies how many keepalives may be lost before the connection is considered dead. A value of zero uses the system default. If TCP_KEEPCNT is not supported, this parameter must be zero. This parameter is ignored for connections made via a Unix-domain socket.
+On systems that support the TCP_KEEPCNT socket option, specifies how many keepalives can be lost before the connection is considered dead. A value of zero uses the system default. If TCP_KEEPCNT is not supported, this parameter must be zero. This parameter is ignored for connections made via a Unix-domain socket.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+This variable specifies tablespace(s) in which to create temporary objects (temp tables and indexes on temp tables) when a CREATE command does not explicitly specify a tablespace. Temporary files for purposes such as sorting large data sets are also created in these tablespace(s). The value is a list of names of tablespaces. When there is more than one name in the list, PostgreSQL chooses a random member of the list each time a temporary object is to be created; except that within a transaction, successively created temporary objects are placed in successive tablespaces from the list. If the selected element of the list is an empty string, PostgreSQL will automatically use the default tablespace of the current database instead. When temp_tablespaces is set interactively, specifying a nonexistent tablespace is an error, as is specifying a tablespace for which the user does not have CREATE privilege. However, when using a previously set value, nonexistent tablespaces are ignored, as are tablespaces for which the user lacks CREATE privilege. In particular, this rule applies when using a value set in postgresql.conf. The default value is an empty string, which results in all temporary objects being created in the default tablespace of the current database. See also default_tablespace.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Enables the collection of information on the currently executing command of each session, along with the time at which that command began execution. This parameter is on by default. Note that even when enabled, this information is not visible to all users, only to superusers and the user owning the session being reported on; so it should not represent a security risk. Only superusers can change this setting.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Enables collection of statistics on database activity. This parameter is on by default, because the autovacuum daemon needs the collected information. Only superusers can change this setting.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Sets the access permissions of the Unix-domain socket. Unix-domain sockets use the usual Unix file system permission set. The parameter value is expected to be a numeric mode specification in the form accepted by the chmod and umask system calls. (To use the customary octal format the number must start with a 0 (zero).) The default permissions are 0777, meaning anyone can connect. Reasonable alternatives are 0770 (only user and group, see also unix_socket_group) and 0700 (only user). (Note that for a Unix-domain socket, only write permission matters and so there is no point in setting or revoking read or execute permissions.) This access control mechanism is independent of the one described in Chapter 20. This parameter can only be set at server start.
+Sets the access permissions of the Unix-domain socket. Unix-domain sockets use the usual Unix file system permission set. The parameter value is expected to be a numeric mode specification in the form accepted by the chmod and umask system calls. (To use the customary octal format the number must start with a 0 (zero).) The default permissions are 0777, meaning anyone can connect. Reasonable alternatives are 0770 (only user and group, see also unix_socket_group) and 0700 (only user). (Note that for a Unix-domain socket, only write permission matters and so there is no point in setting or revoking read or execute permissions.) This access control mechanism is independent of the one described in Chapter 21. This parameter can only be set at server start.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Enables updating of the process title every time a new SQL command is received by the server. The process title is typically viewed by the ps command or in Windows using the Process Explorer. Only superusers can change this setting.
+Enables updating of the process title every time a new SQL command is received by the server. The process title is typically viewed by the ps command, or in Windows by using the Process Explorer. Only superusers can change this setting.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-The length of time, in milliseconds, that the process will sleep when the cost limit has been exceeded. The default value is zero, which disables the cost-based vacuum delay feature. Positive values enable cost-based vacuuming. Note that on many systems, the effective resolution of sleep delays is 10 milliseconds; setting vacuum_cost_delay to a value that is not a multiple of 10 may have the same results as setting it to the next higher multiple of 10.
+The length of time, in milliseconds, that the process will sleep when the cost limit has been exceeded. The default value is zero, which disables the cost-based vacuum delay feature. Positive values enable cost-based vacuuming. Note that on many systems, the effective resolution of sleep delays is 10 milliseconds; setting vacuum_cost_delay to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple of 10.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Specifies the cutoff age (in transactions) that VACUUM should use to decide whether to replace transaction IDs with FrozenXID while scanning a table. The default is 100 million transactions. Although users can set this value anywhere from zero to one billion, VACUUM will silently limit the effective value to half the value of autovacuum_freeze_max_age, so that there is not an unreasonably short time between forced autovacuums. For more information see Section 22.1.3.
+Specifies the cutoff age (in transactions) that VACUUM should use to decide whether to replace transaction IDs with FrozenXID while scanning a table. The default is 100 million transactions. Although users can set this value anywhere from zero to one billion, VACUUM will silently limit the effective value to half the value of autovacuum_freeze_max_age, so that there is not an unreasonably short time between forced autovacuums. For more information see Section 23.1.3.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-The amount of memory used in shared memory for WAL data. The default is 64 kilobytes (64kB). The setting need only be large enough to hold the amount of WAL data generated by one typical transaction, since the data is written out to disk at every transaction commit. This parameter can only be set at server start. Increasing this parameter may cause PostgreSQL to request more System V shared memory than your operating system's default configuration allows. See Section 16.4.1 for information on how to adjust those parameters, if necessary.
+The amount of memory used in shared memory for WAL data. The default is 64 kilobytes (64kB). The setting need only be large enough to hold the amount of WAL data generated by one typical transaction, since the data is written out to disk at every transaction commit. This parameter can only be set at server start. Increasing this parameter might cause PostgreSQL to request more System V shared memory than your operating system's default configuration allows. See Section 17.4.1 for information on how to adjust those parameters, if necessary.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Method used for forcing WAL updates out to disk. If fsync is off then this setting is irrelevant, since updates will not be forced out at all. Possible values are: open_datasync (write WAL files with open() option O_DSYNC) fdatasync (call fdatasync() at each commit) fsync (call fsync() at each commit) fsync_writethrough (call fsync() at each commit, forcing write-through of any disk write cache) open_sync (write WAL files with open() option O_SYNC) The open_* options also use O_DIRECT if available. Not all of these choices are available on all platforms. The default is the first method in the above list that is supported by the platform, except that fdatasync is the default on Linux. This parameter can only be set in the postgresql.conf file or on the server command line.
+Method used for forcing WAL updates out to disk. If fsync is off then this setting is irrelevant, since updates will not be forced out at all. Possible values are: open_datasync (write WAL files with open() option O_DSYNC) fdatasync (call fdatasync() at each commit) fsync (call fsync() at each commit) fsync_writethrough (call fsync() at each commit, forcing write-through of any disk write cache) open_sync (write WAL files with open() option O_SYNC) The open_* options also use O_DIRECT if available. Not all of these choices are available on all platforms. The default is the first method in the above list that is supported by the platform, except that fdatasync is the default on Linux. The default is not necessarily ideal; it might be necessary to change this setting or other aspects of your system configuration in order to create a crash-safe configuration or achieve optimal performance. These aspects are discussed in Section 28.1. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Specifies the delay between activity rounds for the WAL writer. In each round the writer will flush WAL to disk. It then sleeps for wal_writer_delay milliseconds, and repeats. The default value is 200 milliseconds (200ms). Note that on many systems, the effective resolution of sleep delays is 10 milliseconds; setting wal_writer_delay to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple of 10. This parameter can only be set in the postgresql.conf file or on the server command line.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Sets how binary values are to be encoded in XML. This applies for example when bytea values are converted to XML by the functions xmlelement or xmlforest. Possible values are base64 and hex, which are both defined in the XML Schema standard. The default is base64. For further information about XML-related functions, see Section 9.14. The actual choice here is mostly a matter of taste, constrained only by possible restrictions in client applications. Both methods support all possible values, although the hex encoding will be somewhat larger than the base64 encoding.

--- 8.2
+++ 8.3
@@ -0,0 +1,3 @@
+
+
+Sets whether DOCUMENT or CONTENT is implicit when converting between XML and character string values. See Section 8.13 for a description of this. Valid values are DOCUMENT and CONTENT. The default is CONTENT. According to the SQL standard, the command to set this option is SET XML OPTION { DOCUMENT | CONTENT }; This syntax is also available in PostgreSQL.

--- 8.2
+++ 8.3
@@ -1 +1 @@
-Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current command. Setting zero_damaged_pages to on causes the system to instead report a warning, zero out the damaged page, and continue processing. This behavior will destroy data, namely all the rows on the damaged page. But it allows you to get past the error and retrieve rows from any undamaged pages that may be present in the table. So it is useful for recovering data if corruption has occurred due to hardware or software error. You should generally not set this on until you have given up hope of recovering data from the damaged page(s) of a table. The default setting is off, and it can only be changed by a superuser.
+Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current command. Setting zero_damaged_pages to on causes the system to instead report a warning, zero out the damaged page, and continue processing. This behavior will destroy data, namely all the rows on the damaged page. But it allows you to get past the error and retrieve rows from any undamaged pages that might be present in the table. So it is useful for recovering data if corruption has occurred due to hardware or software error. You should generally not set this on until you have given up hope of recovering data from the damaged page(s) of a table. The default setting is off, and it can only be changed by a superuser.