2003-07-18 21:16:03 +02:00
|
|
|
# -----------------------------
|
2000-06-04 03:44:38 +02:00
|
|
|
# PostgreSQL configuration file
|
|
|
|
# -----------------------------
|
|
|
|
#
|
2002-03-09 06:11:38 +01:00
|
|
|
# This file consists of lines of the form:
|
2000-06-04 03:44:38 +02:00
|
|
|
#
|
|
|
|
# name = value
|
|
|
|
#
|
2007-12-07 17:44:56 +01:00
|
|
|
# (The "=" is optional.) Whitespace may be used. Comments are introduced with
|
|
|
|
# "#" anywhere on a line. The complete list of parameter names and allowed
|
|
|
|
# values can be found in the PostgreSQL documentation.
|
2002-03-09 06:11:38 +01:00
|
|
|
#
|
2007-12-07 17:44:56 +01:00
|
|
|
# The commented-out settings shown in this file represent the default values.
|
|
|
|
# Re-commenting a setting is NOT sufficient to revert it to the default value;
|
|
|
|
# you need to reload the server.
|
2004-09-20 19:53:59 +02:00
|
|
|
#
|
2007-12-07 17:44:56 +01:00
|
|
|
# This file is read on server startup and when the server receives a SIGHUP
|
|
|
|
# signal. If you edit the file on a running system, you have to SIGHUP the
|
2016-10-25 17:26:15 +02:00
|
|
|
# server for the changes to take effect, run "pg_ctl reload", or execute
|
|
|
|
# "SELECT pg_reload_conf()". Some parameters, which are marked below,
|
|
|
|
# require a server shutdown and restart to take effect.
|
2002-03-09 06:11:38 +01:00
|
|
|
#
|
2007-12-07 17:44:56 +01:00
|
|
|
# Any parameter can also be given as a command-line option to the server, e.g.,
|
2008-06-11 17:44:52 +02:00
|
|
|
# "postgres -c log_connections=on". Some parameters can be changed at run time
|
2007-12-07 17:44:56 +01:00
|
|
|
# with the "SET" SQL command.
|
2007-01-20 22:42:03 +01:00
|
|
|
#
|
2009-04-06 21:03:04 +02:00
|
|
|
# Memory units: kB = kilobytes Time units: ms = milliseconds
|
|
|
|
# MB = megabytes s = seconds
|
|
|
|
# GB = gigabytes min = minutes
|
2013-06-20 01:17:14 +02:00
|
|
|
# TB = terabytes h = hours
|
2009-04-06 21:03:04 +02:00
|
|
|
# d = days
|
2001-01-24 19:37:31 +01:00
|
|
|
|
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2004-10-08 03:36:36 +02:00
|
|
|
# FILE LOCATIONS
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2004-07-11 02:18:45 +02:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
# The default values of these variables are driven from the -D command-line
|
|
|
|
# option or PGDATA environment variable, represented here as ConfigDir.
|
2005-06-04 20:13:59 +02:00
|
|
|
|
2005-08-21 05:39:37 +02:00
|
|
|
#data_directory = 'ConfigDir' # use data in another directory
|
2006-07-24 12:44:40 +02:00
|
|
|
# (change requires restart)
|
2005-08-21 05:39:37 +02:00
|
|
|
#hba_file = 'ConfigDir/pg_hba.conf' # host-based authentication file
|
2006-07-24 12:44:40 +02:00
|
|
|
# (change requires restart)
|
|
|
|
#ident_file = 'ConfigDir/pg_ident.conf' # ident configuration file
|
|
|
|
# (change requires restart)
|
2004-10-08 03:36:36 +02:00
|
|
|
|
2006-07-24 12:44:40 +02:00
|
|
|
# If external_pid_file is not explicitly set, no extra PID file is written.
|
2011-10-10 14:16:36 +02:00
|
|
|
#external_pid_file = '' # write an extra PID file
|
2006-07-24 12:44:40 +02:00
|
|
|
# (change requires restart)
|
2004-07-11 02:18:45 +02:00
|
|
|
|
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-04 18:41:22 +02:00
|
|
|
# CONNECTIONS AND AUTHENTICATION
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-18 21:16:03 +02:00
|
|
|
|
|
|
|
# - Connection Settings -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#listen_addresses = 'localhost' # what IP address(es) to listen on;
|
2005-09-02 23:25:30 +02:00
|
|
|
# comma-separated list of addresses;
|
2011-08-25 15:39:35 +02:00
|
|
|
# defaults to 'localhost'; use '*' for all
|
2006-07-24 12:44:40 +02:00
|
|
|
# (change requires restart)
|
|
|
|
#port = 5432 # (change requires restart)
|
|
|
|
#max_connections = 100 # (change requires restart)
|
2006-09-03 01:08:36 +02:00
|
|
|
#superuser_reserved_connections = 3 # (change requires restart)
|
2012-08-10 23:26:44 +02:00
|
|
|
#unix_socket_directories = '/tmp' # comma-separated list of directories
|
|
|
|
# (change requires restart)
|
2006-07-24 12:44:40 +02:00
|
|
|
#unix_socket_group = '' # (change requires restart)
|
2007-12-07 17:44:56 +01:00
|
|
|
#unix_socket_permissions = 0777 # begin with 0 to use octal notation
|
2006-07-24 12:44:40 +02:00
|
|
|
# (change requires restart)
|
2009-09-08 19:08:36 +02:00
|
|
|
#bonjour = off # advertise server via Bonjour
|
|
|
|
# (change requires restart)
|
2005-08-19 03:55:18 +02:00
|
|
|
#bonjour_name = '' # defaults to the computer name
|
2006-07-24 12:44:40 +02:00
|
|
|
# (change requires restart)
|
2001-01-24 19:37:31 +01:00
|
|
|
|
Add support TCP user timeout in libpq and the backend server
Similarly to the set of parameters for keepalive, a connection parameter
for libpq is added as well as a backend GUC, called tcp_user_timeout.
Increasing the TCP user timeout is useful to allow a connection to
survive extended periods without end-to-end connection, and decreasing
it allows application to fail faster. By default, the parameter is 0,
which makes the connection use the system default, and follows a logic
close to the keepalive parameters in its handling. When connecting
through a Unix-socket domain, the parameters have no effect.
Author: Ryohei Nagaura
Reviewed-by: Fabien Coelho, Robert Haas, Kyotaro Horiguchi, Kirk
Jamison, Mikalai Keida, Takayuki Tsunakawa, Andrei Yahorau
Discussion: https://postgr.es/m/EDA4195584F5064680D8130B1CA91C45367328@G01JPEXMBYT04
2019-04-06 08:23:37 +02:00
|
|
|
# - TCP settings -
|
2019-07-05 10:59:29 +02:00
|
|
|
# see "man tcp" for details
|
2018-01-19 01:12:05 +01:00
|
|
|
|
|
|
|
#tcp_keepalives_idle = 0 # TCP_KEEPIDLE, in seconds;
|
|
|
|
# 0 selects the system default
|
|
|
|
#tcp_keepalives_interval = 0 # TCP_KEEPINTVL, in seconds;
|
|
|
|
# 0 selects the system default
|
|
|
|
#tcp_keepalives_count = 0 # TCP_KEEPCNT;
|
|
|
|
# 0 selects the system default
|
Add support TCP user timeout in libpq and the backend server
Similarly to the set of parameters for keepalive, a connection parameter
for libpq is added as well as a backend GUC, called tcp_user_timeout.
Increasing the TCP user timeout is useful to allow a connection to
survive extended periods without end-to-end connection, and decreasing
it allows application to fail faster. By default, the parameter is 0,
which makes the connection use the system default, and follows a logic
close to the keepalive parameters in its handling. When connecting
through a Unix-socket domain, the parameters have no effect.
Author: Ryohei Nagaura
Reviewed-by: Fabien Coelho, Robert Haas, Kyotaro Horiguchi, Kirk
Jamison, Mikalai Keida, Takayuki Tsunakawa, Andrei Yahorau
Discussion: https://postgr.es/m/EDA4195584F5064680D8130B1CA91C45367328@G01JPEXMBYT04
2019-04-06 08:23:37 +02:00
|
|
|
#tcp_user_timeout = 0 # TCP_USER_TIMEOUT, in milliseconds;
|
|
|
|
# 0 selects the system default
|
2018-01-19 01:12:05 +01:00
|
|
|
|
|
|
|
# - Authentication -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2006-09-22 19:41:21 +02:00
|
|
|
#authentication_timeout = 1min # 1s-600s
|
2017-09-08 20:38:54 +02:00
|
|
|
#password_encryption = md5 # md5 or scram-sha-256
|
2005-07-02 20:29:04 +02:00
|
|
|
#db_user_namespace = off
|
2005-08-21 05:39:37 +02:00
|
|
|
|
2014-03-16 15:18:52 +01:00
|
|
|
# GSSAPI using Kerberos
|
2009-01-02 12:26:24 +01:00
|
|
|
#krb_server_keyfile = ''
|
|
|
|
#krb_caseins_users = off
|
2001-01-24 19:37:31 +01:00
|
|
|
|
2018-01-19 01:12:05 +01:00
|
|
|
# - SSL -
|
2005-09-12 04:26:33 +02:00
|
|
|
|
2018-01-19 01:12:05 +01:00
|
|
|
#ssl = off
|
|
|
|
#ssl_ca_file = ''
|
|
|
|
#ssl_cert_file = 'server.crt'
|
|
|
|
#ssl_crl_file = ''
|
|
|
|
#ssl_key_file = 'server.key'
|
|
|
|
#ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers
|
|
|
|
#ssl_prefer_server_ciphers = on
|
|
|
|
#ssl_ecdh_curve = 'prime256v1'
|
2019-12-04 21:40:17 +01:00
|
|
|
#ssl_min_protocol_version = 'TLSv1.2'
|
2018-11-20 21:49:01 +01:00
|
|
|
#ssl_max_protocol_version = ''
|
2018-01-19 01:12:05 +01:00
|
|
|
#ssl_dh_params_file = ''
|
2018-02-26 19:28:38 +01:00
|
|
|
#ssl_passphrase_command = ''
|
|
|
|
#ssl_passphrase_command_supports_reload = off
|
2005-09-12 04:26:33 +02:00
|
|
|
|
2001-01-24 19:37:31 +01:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-04 18:41:22 +02:00
|
|
|
# RESOURCE USAGE (except WAL)
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-18 21:16:03 +02:00
|
|
|
|
|
|
|
# - Memory -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2008-03-09 05:56:28 +01:00
|
|
|
#shared_buffers = 32MB # min 128kB
|
2006-07-24 12:44:40 +02:00
|
|
|
# (change requires restart)
|
2014-03-03 19:52:48 +01:00
|
|
|
#huge_pages = try # on, off, or try
|
Allow using huge TLB pages on Linux (MAP_HUGETLB)
This patch adds an option, huge_tlb_pages, which allows requesting the
shared memory segment to be allocated using huge pages, by using the
MAP_HUGETLB flag in mmap(). This can improve performance.
The default is 'try', which means that we will attempt using huge pages,
and fall back to non-huge pages if it doesn't work. Currently, only Linux
has MAP_HUGETLB. On other platforms, the default 'try' behaves the same as
'off'.
In the passing, don't try to round the mmap() size to a multiple of
pagesize. mmap() doesn't require that, and there's no particular reason for
PostgreSQL to do that either. When using MAP_HUGETLB, however, round the
request size up to nearest 2MB boundary. This is to work around a bug in
some Linux kernel versions, but also to avoid wasting memory, because the
kernel will round the size up anyway.
Many people were involved in writing this patch, including Christian Kruse,
Richard Poole, Abhijit Menon-Sen, reviewed by Peter Geoghegan, Andres Freund
and me.
2014-01-29 12:44:45 +01:00
|
|
|
# (change requires restart)
|
2006-10-03 23:11:55 +02:00
|
|
|
#temp_buffers = 8MB # min 800kB
|
2009-04-23 02:23:46 +02:00
|
|
|
#max_prepared_transactions = 0 # zero disables the feature
|
2006-07-24 12:44:40 +02:00
|
|
|
# (change requires restart)
|
2016-07-20 00:41:30 +02:00
|
|
|
# Caution: it is not advisable to set max_prepared_transactions nonzero unless
|
|
|
|
# you actively intend to use prepared transactions.
|
2014-02-24 19:04:51 +01:00
|
|
|
#work_mem = 4MB # min 64kB
|
|
|
|
#maintenance_work_mem = 64MB # min 1MB
|
2013-12-12 12:42:39 +01:00
|
|
|
#autovacuum_work_mem = -1 # min 1MB, or -1 to use maintenance_work_mem
|
Add logical_decoding_work_mem to limit ReorderBuffer memory usage.
Instead of deciding to serialize a transaction merely based on the
number of changes in that xact (toplevel or subxact), this makes
the decisions based on amount of memory consumed by the changes.
The memory limit is defined by a new logical_decoding_work_mem GUC,
so for example we can do this
SET logical_decoding_work_mem = '128kB'
to reduce the memory usage of walsenders or set the higher value to
reduce disk writes. The minimum value is 64kB.
When adding a change to a transaction, we account for the size in
two places. Firstly, in the ReorderBuffer, which is then used to
decide if we reached the total memory limit. And secondly in the
transaction the change belongs to, so that we can pick the largest
transaction to evict (and serialize to disk).
We still use max_changes_in_memory when loading changes serialized
to disk. The trouble is we can't use the memory limit directly as
there might be multiple subxact serialized, we need to read all of
them but we don't know how many are there (and which subxact to
read first).
We do not serialize the ReorderBufferTXN entries, so if there is a
transaction with many subxacts, most memory may be in this type of
objects. Those records are not included in the memory accounting.
We also do not account for INTERNAL_TUPLECID changes, which are
kept in a separate list and not evicted from memory. Transactions
with many CTID changes may consume significant amounts of memory,
but we can't really do much about that.
The current eviction algorithm is very simple - the transaction is
picked merely by size, while it might be useful to also consider age
(LSN) of the changes for example. With the new Generational memory
allocator, evicting the oldest changes would make it more likely
the memory gets actually pfreed.
The logical_decoding_work_mem can be set in postgresql.conf, in which
case it serves as the default for all publishers on that instance.
Author: Tomas Vondra, with changes by Dilip Kumar and Amit Kapila
Reviewed-by: Dilip Kumar and Amit Kapila
Tested-By: Vignesh C
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com
2019-11-16 13:19:33 +01:00
|
|
|
#logical_decoding_work_mem = 64MB # min 64kB
|
2006-09-22 19:41:21 +02:00
|
|
|
#max_stack_depth = 2MB # min 100kB
|
2019-02-03 09:55:39 +01:00
|
|
|
#shared_memory_type = mmap # the default is the first option
|
|
|
|
# supported by the operating system:
|
|
|
|
# mmap
|
|
|
|
# sysv
|
|
|
|
# windows
|
|
|
|
# (change requires restart)
|
2014-05-26 05:20:15 +02:00
|
|
|
#dynamic_shared_memory_type = posix # the default is the first option
|
2013-10-10 03:05:02 +02:00
|
|
|
# supported by the operating system:
|
|
|
|
# posix
|
|
|
|
# sysv
|
|
|
|
# windows
|
|
|
|
# mmap
|
2017-07-31 04:06:37 +02:00
|
|
|
# (change requires restart)
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2011-07-17 20:19:31 +02:00
|
|
|
# - Disk -
|
|
|
|
|
2016-07-07 17:18:51 +02:00
|
|
|
#temp_file_limit = -1 # limits per-process temp file space
|
2011-07-17 20:19:31 +02:00
|
|
|
# in kB, or -1 for no limit
|
|
|
|
|
2018-06-04 21:34:42 +02:00
|
|
|
# - Kernel Resources -
|
2001-06-28 01:31:40 +02:00
|
|
|
|
2005-08-19 03:55:18 +02:00
|
|
|
#max_files_per_process = 1000 # min 25
|
2006-07-24 12:44:40 +02:00
|
|
|
# (change requires restart)
|
2001-01-24 19:37:31 +01:00
|
|
|
|
2004-08-08 21:42:57 +02:00
|
|
|
# - Cost-Based Vacuum Delay -
|
|
|
|
|
2019-03-10 20:01:39 +01:00
|
|
|
#vacuum_cost_delay = 0 # 0-100 milliseconds (0 disables)
|
2005-08-19 03:55:18 +02:00
|
|
|
#vacuum_cost_page_hit = 1 # 0-10000 credits
|
|
|
|
#vacuum_cost_page_miss = 10 # 0-10000 credits
|
|
|
|
#vacuum_cost_page_dirty = 20 # 0-10000 credits
|
2019-03-10 20:05:25 +01:00
|
|
|
#vacuum_cost_limit = 200 # 1-10000 credits
|
2004-08-08 21:42:57 +02:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
# - Background Writer -
|
2004-08-08 21:42:57 +02:00
|
|
|
|
2006-09-22 19:41:21 +02:00
|
|
|
#bgwriter_delay = 200ms # 10-10000ms between rounds
|
2017-11-17 20:52:00 +01:00
|
|
|
#bgwriter_lru_maxpages = 100 # max buffers written/round, 0 disables
|
2015-11-14 20:00:17 +01:00
|
|
|
#bgwriter_lru_multiplier = 2.0 # 0-10.0 multiplier on buffers scanned/round
|
2016-11-26 00:36:10 +01:00
|
|
|
#bgwriter_flush_after = 0 # measured in pages, 0 disables
|
2004-08-08 21:42:57 +02:00
|
|
|
|
2009-01-12 06:10:45 +01:00
|
|
|
# - Asynchronous Behavior -
|
|
|
|
|
2012-05-14 03:14:35 +02:00
|
|
|
#effective_io_concurrency = 1 # 1-1000; 0 disables prefetching
|
2016-12-05 16:53:21 +01:00
|
|
|
#max_worker_processes = 8 # (change requires restart)
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
#max_parallel_maintenance_workers = 2 # taken from max_parallel_workers
|
2017-03-07 21:30:03 +01:00
|
|
|
#max_parallel_workers_per_gather = 2 # taken from max_parallel_workers
|
2017-11-15 14:37:32 +01:00
|
|
|
#parallel_leader_participation = on
|
2017-06-09 20:38:33 +02:00
|
|
|
#max_parallel_workers = 8 # maximum number of max_worker_processes that
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
# can be used in parallel operations
|
2016-04-08 21:36:30 +02:00
|
|
|
#old_snapshot_threshold = -1 # 1min-60d; -1 disables; 0 is immediate
|
2016-10-27 03:16:20 +02:00
|
|
|
# (change requires restart)
|
2016-11-26 00:36:10 +01:00
|
|
|
#backend_flush_after = 0 # measured in pages, 0 disables
|
2009-01-12 06:10:45 +01:00
|
|
|
|
2001-01-24 19:37:31 +01:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2017-11-16 18:57:17 +01:00
|
|
|
# WRITE-AHEAD LOG
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-18 21:16:03 +02:00
|
|
|
|
|
|
|
# - Settings -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2017-01-14 17:14:56 +01:00
|
|
|
#wal_level = replica # minimal, replica, or logical
|
2010-09-27 15:14:14 +02:00
|
|
|
# (change requires restart)
|
2016-04-27 19:46:26 +02:00
|
|
|
#fsync = on # flush data to disk for crash safety
|
2016-10-27 03:16:20 +02:00
|
|
|
# (turning this off can cause
|
|
|
|
# unrecoverable data corruption)
|
2012-04-14 16:53:22 +02:00
|
|
|
#synchronous_commit = on # synchronization level;
|
2016-03-30 03:16:12 +02:00
|
|
|
# off, local, remote_write, remote_apply, or on
|
2010-11-23 21:27:50 +01:00
|
|
|
#wal_sync_method = fsync # the default is the first option
|
2005-08-19 03:55:18 +02:00
|
|
|
# supported by the operating system:
|
|
|
|
# open_datasync
|
2010-12-09 02:01:09 +01:00
|
|
|
# fdatasync (default on Linux)
|
2005-08-19 03:55:18 +02:00
|
|
|
# fsync
|
|
|
|
# fsync_writethrough
|
|
|
|
# open_sync
|
|
|
|
#full_page_writes = on # recover from partial page writes
|
Add GUC to enable compression of full page images stored in WAL.
When newly-added GUC parameter, wal_compression, is on, the PostgreSQL server
compresses a full page image written to WAL when full_page_writes is on or
during a base backup. A compressed page image will be decompressed during WAL
replay. Turning this parameter on can reduce the WAL volume without increasing
the risk of unrecoverable data corruption, but at the cost of some extra CPU
spent on the compression during WAL logging and on the decompression during
WAL replay.
This commit changes the WAL format (so bumping WAL version number) so that
the one-byte flag indicating whether a full page image is compressed or not is
included in its header information. This means that the commit increases the
WAL volume one-byte per a full page image even if WAL compression is not used
at all. We can save that one-byte by borrowing one-bit from the existing field
like hole_offset in the header and using it as the flag, for example. But which
would reduce the code readability and the extensibility of the feature.
Per discussion, it's not worth paying those prices to save only one-byte, so we
decided to add the one-byte flag to the header.
This commit doesn't introduce any new compression algorithm like lz4.
Currently a full page image is compressed using the existing PGLZ algorithm.
Per discussion, we decided to use it at least in the first version of the
feature because there were no performance reports showing that its compression
ratio is unacceptably lower than that of other algorithm. Of course,
in the future, it's worth considering the support of other compression
algorithm for the better compression.
Rahila Syed and Michael Paquier, reviewed in various versions by myself,
Andres Freund, Robert Haas, Abhijit Menon-Sen and many others.
2015-03-11 07:52:24 +01:00
|
|
|
#wal_compression = off # enable compression of full-page writes
|
2014-05-26 05:20:15 +02:00
|
|
|
#wal_log_hints = off # also do full page writes of non-critical updates
|
2014-12-05 10:58:24 +01:00
|
|
|
# (change requires restart)
|
2019-04-02 03:37:14 +02:00
|
|
|
#wal_init_zero = on # zero-fill new WAL files
|
|
|
|
#wal_recycle = on # recycle WAL files
|
2011-01-23 02:31:24 +01:00
|
|
|
#wal_buffers = -1 # min 32kB, -1 sets based on shared_buffers
|
2006-07-24 12:44:40 +02:00
|
|
|
# (change requires restart)
|
2007-12-07 17:44:56 +01:00
|
|
|
#wal_writer_delay = 200ms # 1-10000 milliseconds
|
2016-11-26 00:36:10 +01:00
|
|
|
#wal_writer_flush_after = 1MB # measured in pages, 0 disables
|
2007-07-24 06:54:09 +02:00
|
|
|
|
2005-08-19 03:55:18 +02:00
|
|
|
#commit_delay = 0 # range 0-100000, in microseconds
|
|
|
|
#commit_siblings = 5 # range 1-1000
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2003-07-18 21:16:03 +02:00
|
|
|
# - Checkpoints -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2016-09-12 00:26:18 +02:00
|
|
|
#checkpoint_timeout = 5min # range 30s-1d
|
2015-03-15 17:37:07 +01:00
|
|
|
#max_wal_size = 1GB
|
2015-02-23 17:53:02 +01:00
|
|
|
#min_wal_size = 80MB
|
2007-06-28 02:02:40 +02:00
|
|
|
#checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0
|
2016-11-26 00:36:10 +01:00
|
|
|
#checkpoint_flush_after = 0 # measured in pages, 0 disables
|
2009-04-08 00:22:19 +02:00
|
|
|
#checkpoint_warning = 30s # 0 disables
|
2001-08-21 18:31:23 +02:00
|
|
|
|
2004-07-19 04:47:16 +02:00
|
|
|
# - Archiving -
|
|
|
|
|
2015-05-15 17:55:24 +02:00
|
|
|
#archive_mode = off # enables archiving; off, on, or always
|
2007-09-27 00:36:30 +02:00
|
|
|
# (change requires restart)
|
2006-08-18 01:04:10 +02:00
|
|
|
#archive_command = '' # command to use to archive a logfile segment
|
2011-09-03 00:29:09 +02:00
|
|
|
# placeholders: %p = path of file to archive
|
|
|
|
# %f = file name only
|
|
|
|
# e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
|
2006-08-18 01:04:10 +02:00
|
|
|
#archive_timeout = 0 # force a logfile segment switch after this
|
2009-04-08 00:22:19 +02:00
|
|
|
# number of seconds; 0 disables
|
2004-08-12 20:32:52 +02:00
|
|
|
|
2018-11-25 16:31:16 +01:00
|
|
|
# - Archive Recovery -
|
|
|
|
|
|
|
|
# These are only used in recovery mode.
|
|
|
|
|
|
|
|
#restore_command = '' # command to use to restore an archived logfile segment
|
|
|
|
# placeholders: %p = path of file to restore
|
|
|
|
# %f = file name only
|
|
|
|
# e.g. 'cp /mnt/server/archivedir/%f %p'
|
|
|
|
# (change requires restart)
|
|
|
|
#archive_cleanup_command = '' # command to execute at every restartpoint
|
|
|
|
#recovery_end_command = '' # command to execute at completion of recovery
|
|
|
|
|
|
|
|
# - Recovery Target -
|
|
|
|
|
|
|
|
# Set these only when performing a targeted recovery.
|
|
|
|
|
|
|
|
#recovery_target = '' # 'immediate' to end recovery as soon as a
|
|
|
|
# consistent state is reached
|
|
|
|
# (change requires restart)
|
|
|
|
#recovery_target_name = '' # the named restore point to which recovery will proceed
|
|
|
|
# (change requires restart)
|
|
|
|
#recovery_target_time = '' # the time stamp up to which recovery will proceed
|
|
|
|
# (change requires restart)
|
|
|
|
#recovery_target_xid = '' # the transaction ID up to which recovery will proceed
|
|
|
|
# (change requires restart)
|
|
|
|
#recovery_target_lsn = '' # the WAL LSN up to which recovery will proceed
|
|
|
|
# (change requires restart)
|
|
|
|
#recovery_target_inclusive = on # Specifies whether to stop:
|
|
|
|
# just after the specified recovery target (on)
|
|
|
|
# just before the recovery target (off)
|
|
|
|
# (change requires restart)
|
2019-01-11 10:36:10 +01:00
|
|
|
#recovery_target_timeline = 'latest' # 'current', 'latest', or timeline ID
|
2018-11-25 16:31:16 +01:00
|
|
|
# (change requires restart)
|
|
|
|
#recovery_target_action = 'pause' # 'pause', 'promote', 'shutdown'
|
|
|
|
# (change requires restart)
|
|
|
|
|
2011-03-06 23:49:16 +01:00
|
|
|
|
2011-07-07 21:10:32 +02:00
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
# REPLICATION
|
|
|
|
#------------------------------------------------------------------------------
|
2011-03-06 23:49:16 +01:00
|
|
|
|
2017-11-16 18:57:17 +01:00
|
|
|
# - Sending Servers -
|
2011-07-07 21:10:32 +02:00
|
|
|
|
2012-05-14 03:14:35 +02:00
|
|
|
# Set these on the master and on any standby that will send replication data.
|
2010-06-15 09:52:11 +02:00
|
|
|
|
2017-01-14 17:14:56 +01:00
|
|
|
#max_wal_senders = 10 # max number of walsender processes
|
2010-09-27 15:14:14 +02:00
|
|
|
# (change requires restart)
|
Make WAL segment size configurable at initdb time.
For performance reasons a larger segment size than the default 16MB
can be useful. A larger segment size has two main benefits: Firstly,
in setups using archiving, it makes it easier to write scripts that
can keep up with higher amounts of WAL, secondly, the WAL has to be
written and synced to disk less frequently.
But at the same time large segment size are disadvantageous for
smaller databases. So far the segment size had to be configured at
compile time, often making it unrealistic to choose one fitting to a
particularly load. Therefore change it to a initdb time setting.
This includes a breaking changes to the xlogreader.h API, which now
requires the current segment size to be configured. For that and
similar reasons a number of binaries had to be taught how to recognize
the current segment size.
Author: Beena Emerson, editorialized by Andres Freund
Reviewed-By: Andres Freund, David Steele, Kuntal Ghosh, Michael
Paquier, Peter Eisentraut, Robert Hass, Tushar Ahuja
Discussion: https://postgr.es/m/CAOG9ApEAcQ--1ieKbhFzXSQPw_YLmepaa4hNdnY5+ZULpt81Mw@mail.gmail.com
2017-09-20 07:03:48 +02:00
|
|
|
#wal_keep_segments = 0 # in logfile segments; 0 disables
|
2012-10-11 16:39:52 +02:00
|
|
|
#wal_sender_timeout = 60s # in milliseconds; 0 disables
|
2011-07-19 09:59:55 +02:00
|
|
|
|
2017-01-14 17:14:56 +01:00
|
|
|
#max_replication_slots = 10 # max number of replication slots
|
2014-02-01 04:45:17 +01:00
|
|
|
# (change requires restart)
|
Keep track of transaction commit timestamps
Transactions can now set their commit timestamp directly as they commit,
or an external transaction commit timestamp can be fed from an outside
system using the new function TransactionTreeSetCommitTsData(). This
data is crash-safe, and truncated at Xid freeze point, same as pg_clog.
This module is disabled by default because it causes a performance hit,
but can be enabled in postgresql.conf requiring only a server restart.
A new test in src/test/modules is included.
Catalog version bumped due to the new subdirectory within PGDATA and a
couple of new SQL functions.
Authors: Álvaro Herrera and Petr Jelínek
Reviewed to varying degrees by Michael Paquier, Andres Freund, Robert
Haas, Amit Kapila, Fujii Masao, Jaime Casanova, Simon Riggs, Steven
Singer, Peter Eisentraut
2014-12-03 15:53:02 +01:00
|
|
|
#track_commit_timestamp = off # collect timestamp of transaction commit
|
|
|
|
# (change requires restart)
|
2014-02-01 04:45:17 +01:00
|
|
|
|
2011-07-19 09:59:55 +02:00
|
|
|
# - Master Server -
|
|
|
|
|
2012-05-14 03:14:35 +02:00
|
|
|
# These settings are ignored on a standby server.
|
2011-07-19 09:59:55 +02:00
|
|
|
|
2011-07-07 21:10:32 +02:00
|
|
|
#synchronous_standby_names = '' # standby servers that provide sync rep
|
2017-06-09 20:38:33 +02:00
|
|
|
# method to choose sync standbys, number of sync standbys,
|
2016-12-19 13:15:30 +01:00
|
|
|
# and comma-separated list of application_name
|
2011-07-07 21:10:32 +02:00
|
|
|
# from standby(s); '*' = all
|
2011-07-19 09:59:55 +02:00
|
|
|
#vacuum_defer_cleanup_age = 0 # number of xacts by which cleanup is delayed
|
2010-06-15 09:52:11 +02:00
|
|
|
|
|
|
|
# - Standby Servers -
|
2010-01-29 19:39:05 +01:00
|
|
|
|
2012-05-14 03:14:35 +02:00
|
|
|
# These settings are ignored on a master server.
|
2011-07-07 21:10:32 +02:00
|
|
|
|
2018-11-25 16:31:16 +01:00
|
|
|
#primary_conninfo = '' # connection string to sending server
|
|
|
|
# (change requires restart)
|
|
|
|
#primary_slot_name = '' # replication slot on sending server
|
|
|
|
# (change requires restart)
|
|
|
|
#promote_trigger_file = '' # file name whose presence ends recovery
|
2017-05-02 11:12:30 +02:00
|
|
|
#hot_standby = on # "off" disallows queries during recovery
|
2010-09-27 15:14:14 +02:00
|
|
|
# (change requires restart)
|
2010-07-03 22:43:58 +02:00
|
|
|
#max_standby_archive_delay = 30s # max delay before canceling queries
|
|
|
|
# when reading WAL from archive;
|
|
|
|
# -1 allows indefinite delay
|
|
|
|
#max_standby_streaming_delay = 30s # max delay before canceling queries
|
|
|
|
# when reading streaming WAL;
|
|
|
|
# -1 allows indefinite delay
|
2011-07-07 21:10:32 +02:00
|
|
|
#wal_receiver_status_interval = 10s # send replies at least this often
|
|
|
|
# 0 disables
|
|
|
|
#hot_standby_feedback = off # send info from standby to prevent
|
|
|
|
# query conflicts
|
2012-10-11 16:39:52 +02:00
|
|
|
#wal_receiver_timeout = 60s # time that receiver waits for
|
|
|
|
# communication from master
|
|
|
|
# in milliseconds; 0 disables
|
2015-02-23 12:55:17 +01:00
|
|
|
#wal_retrieve_retry_interval = 5s # time to wait before retrying to
|
|
|
|
# retrieve WAL after a failed attempt
|
2018-11-25 16:31:16 +01:00
|
|
|
#recovery_min_apply_delay = 0 # minimum delay for applying changes during recovery
|
2001-08-21 18:31:23 +02:00
|
|
|
|
2017-04-11 17:10:54 +02:00
|
|
|
# - Subscribers -
|
|
|
|
|
|
|
|
# These settings are ignored on a publisher.
|
|
|
|
|
|
|
|
#max_logical_replication_workers = 4 # taken from max_worker_processes
|
2017-07-31 03:46:32 +02:00
|
|
|
# (change requires restart)
|
2017-04-11 17:10:54 +02:00
|
|
|
#max_sync_workers_per_subscription = 2 # taken from max_logical_replication_workers
|
|
|
|
|
2010-01-15 10:19:10 +01:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-04 18:41:22 +02:00
|
|
|
# QUERY TUNING
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-18 21:16:03 +02:00
|
|
|
|
2003-12-01 23:08:02 +01:00
|
|
|
# - Planner Method Configuration -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2005-07-02 20:29:04 +02:00
|
|
|
#enable_bitmapscan = on
|
|
|
|
#enable_hashagg = on
|
|
|
|
#enable_hashjoin = on
|
|
|
|
#enable_indexscan = on
|
2011-10-08 02:13:02 +02:00
|
|
|
#enable_indexonlyscan = on
|
2010-04-19 02:55:26 +02:00
|
|
|
#enable_material = on
|
2005-07-02 20:29:04 +02:00
|
|
|
#enable_mergejoin = on
|
|
|
|
#enable_nestloop = on
|
Support Parallel Append plan nodes.
When we create an Append node, we can spread out the workers over the
subplans instead of piling on to each subplan one at a time, which
should typically be a bit more efficient, both because the startup
cost of any plan executed entirely by one worker is paid only once and
also because of reduced contention. We can also construct Append
plans using a mix of partial and non-partial subplans, which may allow
for parallelism in places that otherwise couldn't support it.
Unfortunately, this patch doesn't handle the important case of
parallelizing UNION ALL by running each branch in a separate worker;
the executor infrastructure is added here, but more planner work is
needed.
Amit Khandekar, Robert Haas, Amul Sul, reviewed and tested by
Ashutosh Bapat, Amit Langote, Rafia Sabih, Amit Kapila, and
Rajkumar Raghuwanshi.
Discussion: http://postgr.es/m/CAJ3gD9dy0K_E8r727heqXoBmWZ83HwLFwdcaSSmBQ1+S+vRuUQ@mail.gmail.com
2017-12-05 23:28:39 +01:00
|
|
|
#enable_parallel_append = on
|
2005-07-02 20:29:04 +02:00
|
|
|
#enable_seqscan = on
|
|
|
|
#enable_sort = on
|
|
|
|
#enable_tidscan = on
|
2018-02-16 16:33:59 +01:00
|
|
|
#enable_partitionwise_join = off
|
Implement partition-wise grouping/aggregation.
If the partition keys of input relation are part of the GROUP BY
clause, all the rows belonging to a given group come from a single
partition. This allows aggregation/grouping over a partitioned
relation to be broken down * into aggregation/grouping on each
partition. This should be no worse, and often better, than the normal
approach.
If the GROUP BY clause does not contain all the partition keys, we can
still perform partial aggregation for each partition and then finalize
aggregation after appending the partial results. This is less certain
to be a win, but it's still useful.
Jeevan Chalke, Ashutosh Bapat, Robert Haas. The larger patch series
of which this patch is a part was also reviewed and tested by Antonin
Houska, Rajkumar Raghuwanshi, David Rowley, Dilip Kumar, Konstantin
Knizhnik, Pascal Legrand, and Rafia Sabih.
Discussion: http://postgr.es/m/CAM2+6=V64_xhstVHie0Rz=KPEQnLJMZt_e314P0jaT_oJ9MR8A@mail.gmail.com
2018-03-22 17:49:48 +01:00
|
|
|
#enable_partitionwise_aggregate = off
|
Add parallel-aware hash joins.
Introduce parallel-aware hash joins that appear in EXPLAIN plans as Parallel
Hash Join with Parallel Hash. While hash joins could already appear in
parallel queries, they were previously always parallel-oblivious and had a
partial subplan only on the outer side, meaning that the work of the inner
subplan was duplicated in every worker.
After this commit, the planner will consider using a partial subplan on the
inner side too, using the Parallel Hash node to divide the work over the
available CPU cores and combine its results in shared memory. If the join
needs to be split into multiple batches in order to respect work_mem, then
workers process different batches as much as possible and then work together
on the remaining batches.
The advantages of a parallel-aware hash join over a parallel-oblivious hash
join used in a parallel query are that it:
* avoids wasting memory on duplicated hash tables
* avoids wasting disk space on duplicated batch files
* divides the work of building the hash table over the CPUs
One disadvantage is that there is some communication between the participating
CPUs which might outweigh the benefits of parallelism in the case of small
hash tables. This is avoided by the planner's existing reluctance to supply
partial plans for small scans, but it may be necessary to estimate
synchronization costs in future if that situation changes. Another is that
outer batch 0 must be written to disk if multiple batches are required.
A potential future advantage of parallel-aware hash joins is that right and
full outer joins could be supported, since there is a single set of matched
bits for each hashtable, but that is not yet implemented.
A new GUC enable_parallel_hash is defined to control the feature, defaulting
to on.
Author: Thomas Munro
Reviewed-By: Andres Freund, Robert Haas
Tested-By: Rafia Sabih, Prabhat Sahu
Discussion:
https://postgr.es/m/CAEepm=2W=cOkiZxcg6qiFQP-dHUe09aqTrEMM7yJDrHMhDv_RA@mail.gmail.com
https://postgr.es/m/CAEepm=37HKyJ4U6XOLi=JgfSHM3o6B-GaeO-6hkOmneTDkH+Uw@mail.gmail.com
2017-12-21 08:39:21 +01:00
|
|
|
#enable_parallel_hash = on
|
2018-04-23 22:57:43 +02:00
|
|
|
#enable_partition_pruning = on
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2003-07-18 21:16:03 +02:00
|
|
|
# - Planner Cost Constants -
|
2001-01-24 19:37:31 +01:00
|
|
|
|
2006-06-05 04:49:58 +02:00
|
|
|
#seq_page_cost = 1.0 # measured on an arbitrary scale
|
|
|
|
#random_page_cost = 4.0 # same scale as above
|
|
|
|
#cpu_tuple_cost = 0.01 # same scale as above
|
2006-06-05 05:03:42 +02:00
|
|
|
#cpu_index_tuple_cost = 0.005 # same scale as above
|
2006-06-05 04:49:58 +02:00
|
|
|
#cpu_operator_cost = 0.0025 # same scale as above
|
Add a Gather executor node.
A Gather executor node runs any number of copies of a plan in an equal
number of workers and merges all of the results into a single tuple
stream. It can also run the plan itself, if the workers are
unavailable or haven't started up yet. It is intended to work with
the Partial Seq Scan node which will be added in future commits.
It could also be used to implement parallel query of a different sort
by itself, without help from Partial Seq Scan, if the single_copy mode
is used. In that mode, a worker executes the plan, and the parallel
leader does not, merely collecting the worker's results. So, a Gather
node could be inserted into a plan to split the execution of that plan
across two processes. Nested Gather nodes aren't currently supported,
but we might want to add support for that in the future.
There's nothing in the planner to actually generate Gather nodes yet,
so it's not quite time to break out the champagne. But we're getting
close.
Amit Kapila. Some designs suggestions were provided by me, and I also
reviewed the patch. Single-copy mode, documentation, and other minor
changes also by me.
2015-10-01 01:23:36 +02:00
|
|
|
#parallel_tuple_cost = 0.1 # same scale as above
|
|
|
|
#parallel_setup_cost = 1000.0 # same scale as above
|
2018-03-22 19:45:07 +01:00
|
|
|
|
|
|
|
#jit_above_cost = 100000 # perform JIT compilation if available
|
2018-09-15 23:24:35 +02:00
|
|
|
# and query more expensive than this;
|
|
|
|
# -1 disables
|
|
|
|
#jit_inline_above_cost = 500000 # inline small functions if query is
|
|
|
|
# more expensive than this; -1 disables
|
|
|
|
#jit_optimize_above_cost = 500000 # use expensive JIT optimizations if
|
|
|
|
# query is more expensive than this;
|
2018-03-28 22:19:08 +02:00
|
|
|
# -1 disables
|
2018-03-22 19:45:07 +01:00
|
|
|
|
Replace min_parallel_relation_size with two new GUCs.
When min_parallel_relation_size was added, the only supported type
of parallel scan was a parallel sequential scan, but there are
pending patches for parallel index scan, parallel index-only scan,
and parallel bitmap heap scan. Those patches introduce two new
types of complications: first, what's relevant is not really the
total size of the relation but the portion of it that we will scan;
and second, index pages and heap pages shouldn't necessarily be
treated in exactly the same way. Typically, the number of index
pages will be quite small, but that doesn't necessarily mean that
a parallel index scan can't pay off.
Therefore, we introduce min_parallel_table_scan_size, which works
out a degree of parallelism for scans based on the number of table
pages that will be scanned (and which is therefore equivalent to
min_parallel_relation_size for parallel sequential scans) and also
min_parallel_index_scan_size which can be used to work out a degree
of parallelism based on the number of index pages that will be
scanned.
Amit Kapila and Robert Haas
Discussion: http://postgr.es/m/CAA4eK1KowGSYYVpd2qPpaPPA5R90r++QwDFbrRECTE9H_HvpOg@mail.gmail.com
Discussion: http://postgr.es/m/CAA4eK1+TnM4pXQbvn7OXqam+k_HZqb0ROZUMxOiL6DWJYCyYow@mail.gmail.com
2017-02-15 19:37:24 +01:00
|
|
|
#min_parallel_table_scan_size = 8MB
|
|
|
|
#min_parallel_index_scan_size = 512kB
|
2014-05-09 03:11:47 +02:00
|
|
|
#effective_cache_size = 4GB
|
2001-01-24 19:37:31 +01:00
|
|
|
|
2003-07-18 21:16:03 +02:00
|
|
|
# - Genetic Query Optimizer -
|
2001-01-24 19:37:31 +01:00
|
|
|
|
2005-07-02 20:29:04 +02:00
|
|
|
#geqo = on
|
2004-01-24 00:54:21 +01:00
|
|
|
#geqo_threshold = 12
|
2005-08-19 03:55:18 +02:00
|
|
|
#geqo_effort = 5 # range 1-10
|
|
|
|
#geqo_pool_size = 0 # selects default based on effort
|
|
|
|
#geqo_generations = 0 # selects default based on effort
|
|
|
|
#geqo_selection_bias = 2.0 # range 1.5-2.0
|
2009-07-16 22:55:44 +02:00
|
|
|
#geqo_seed = 0.0 # range 0.0-1.0
|
2001-01-24 19:37:31 +01:00
|
|
|
|
2003-07-18 21:16:03 +02:00
|
|
|
# - Other Planner Options -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2008-12-13 20:13:44 +01:00
|
|
|
#default_statistics_target = 100 # range 1-10000
|
2009-01-07 23:40:49 +01:00
|
|
|
#constraint_exclusion = partition # on, off, or partition
|
2008-05-02 23:26:10 +02:00
|
|
|
#cursor_tuple_fraction = 0.1 # range 0.0-1.0
|
2003-07-04 18:41:22 +02:00
|
|
|
#from_collapse_limit = 8
|
2010-11-23 21:27:50 +01:00
|
|
|
#join_collapse_limit = 8 # 1 disables collapsing of explicit
|
2007-12-07 17:44:56 +01:00
|
|
|
# JOIN clauses
|
2016-02-07 17:39:22 +01:00
|
|
|
#force_parallel_mode = off
|
2018-09-15 23:24:35 +02:00
|
|
|
#jit = on # allow JIT compilation
|
2018-08-22 11:28:39 +02:00
|
|
|
#plan_cache_mode = auto # auto, force_generic_plan or
|
|
|
|
# force_custom_plan
|
2003-07-04 18:41:22 +02:00
|
|
|
|
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2017-11-16 18:57:17 +01:00
|
|
|
# REPORTING AND LOGGING
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-18 21:16:03 +02:00
|
|
|
|
2004-04-05 05:02:11 +02:00
|
|
|
# - Where to Log -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#log_destination = 'stderr' # Valid values are combinations of
|
2010-03-30 02:11:45 +02:00
|
|
|
# stderr, csvlog, syslog, and eventlog,
|
2007-12-07 17:44:56 +01:00
|
|
|
# depending on platform. csvlog
|
|
|
|
# requires logging_collector to be on.
|
2004-08-06 01:32:13 +02:00
|
|
|
|
2005-07-02 20:29:04 +02:00
|
|
|
# This is used when logging to stderr:
|
2007-12-07 17:44:56 +01:00
|
|
|
#logging_collector = off # Enable capturing of stderr and csvlog
|
|
|
|
# into log files. Required to be on for
|
|
|
|
# csvlogs.
|
2006-07-24 12:44:40 +02:00
|
|
|
# (change requires restart)
|
2005-07-02 20:29:04 +02:00
|
|
|
|
2007-08-19 03:41:25 +02:00
|
|
|
# These are only used if logging_collector is on:
|
2017-03-27 16:34:33 +02:00
|
|
|
#log_directory = 'log' # directory where log files are written,
|
2007-12-07 17:44:56 +01:00
|
|
|
# can be absolute or relative to PGDATA
|
|
|
|
#log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name pattern,
|
|
|
|
# can include strftime() escapes
|
2010-07-17 00:25:51 +02:00
|
|
|
#log_file_mode = 0600 # creation mode for log files,
|
|
|
|
# begin with 0 to use octal notation
|
2010-10-08 21:10:06 +02:00
|
|
|
#log_truncate_on_rotation = off # If on, an existing log file with the
|
2007-12-07 17:44:56 +01:00
|
|
|
# same name as the new log file will be
|
|
|
|
# truncated rather than appended to.
|
|
|
|
# But such truncation only occurs on
|
2005-08-19 03:55:18 +02:00
|
|
|
# time-driven rotation, not on restarts
|
2007-12-07 17:44:56 +01:00
|
|
|
# or size-driven rotation. Default is
|
2005-08-19 03:55:18 +02:00
|
|
|
# off, meaning append to existing files
|
|
|
|
# in all cases.
|
2007-12-07 17:44:56 +01:00
|
|
|
#log_rotation_age = 1d # Automatic rotation of logfiles will
|
2009-04-08 00:22:19 +02:00
|
|
|
# happen after that time. 0 disables.
|
2010-11-23 21:27:50 +01:00
|
|
|
#log_rotation_size = 10MB # Automatic rotation of logfiles will
|
2007-12-07 17:44:56 +01:00
|
|
|
# happen after that much log output.
|
2009-04-08 00:22:19 +02:00
|
|
|
# 0 disables.
|
2004-08-06 01:32:13 +02:00
|
|
|
|
|
|
|
# These are relevant when logging to syslog:
|
2003-07-04 18:41:22 +02:00
|
|
|
#syslog_facility = 'LOCAL0'
|
|
|
|
#syslog_ident = 'postgres'
|
2016-02-27 04:34:30 +01:00
|
|
|
#syslog_sequence_numbers = on
|
2016-03-16 03:48:53 +01:00
|
|
|
#syslog_split_messages = on
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2011-10-25 20:02:55 +02:00
|
|
|
# This is only relevant when logging to eventlog (win32):
|
2017-07-31 04:24:51 +02:00
|
|
|
# (change requires restart)
|
2011-10-25 20:02:55 +02:00
|
|
|
#event_source = 'PostgreSQL'
|
2004-08-06 01:32:13 +02:00
|
|
|
|
2003-07-18 21:16:03 +02:00
|
|
|
# - When to Log -
|
2001-01-24 19:37:31 +01:00
|
|
|
|
2008-03-10 04:22:29 +01:00
|
|
|
#log_min_messages = warning # values in order of decreasing detail:
|
2005-08-19 03:55:18 +02:00
|
|
|
# debug5
|
|
|
|
# debug4
|
|
|
|
# debug3
|
|
|
|
# debug2
|
|
|
|
# debug1
|
|
|
|
# info
|
|
|
|
# notice
|
|
|
|
# warning
|
|
|
|
# error
|
|
|
|
# log
|
|
|
|
# fatal
|
|
|
|
# panic
|
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#log_min_error_statement = error # values in order of decreasing detail:
|
2013-11-10 15:20:52 +01:00
|
|
|
# debug5
|
2005-08-19 03:55:18 +02:00
|
|
|
# debug4
|
|
|
|
# debug3
|
|
|
|
# debug2
|
|
|
|
# debug1
|
2013-11-10 15:20:52 +01:00
|
|
|
# info
|
2005-08-19 03:55:18 +02:00
|
|
|
# notice
|
|
|
|
# warning
|
|
|
|
# error
|
2007-03-03 00:37:23 +01:00
|
|
|
# log
|
2006-11-21 02:23:37 +01:00
|
|
|
# fatal
|
|
|
|
# panic (effectively off)
|
2006-05-11 21:15:36 +02:00
|
|
|
|
2019-08-04 20:29:00 +02:00
|
|
|
#log_min_duration_statement = -1 # -1 is disabled, 0 logs all statements
|
|
|
|
# and their durations, > 0 logs only
|
|
|
|
# statements running at least this number
|
|
|
|
# of milliseconds
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2019-11-04 01:57:45 +01:00
|
|
|
#log_min_duration_sample = -1 # -1 is disabled, 0 logs a sample of statements
|
|
|
|
# and their durations, > 0 logs only a sample of
|
|
|
|
# statements running at least this number
|
|
|
|
# of milliseconds
|
|
|
|
# Sample fraction is determined by log_statement_sample_rate
|
|
|
|
|
|
|
|
#log_statement_sample_rate = 1.0 # Fraction of logged statements exceeding
|
|
|
|
# log_min_duration_sample to be logged.
|
|
|
|
# 1.0 logs all such statements, 0.0 never logs.
|
|
|
|
|
|
|
|
|
2019-04-03 23:43:59 +02:00
|
|
|
#log_transaction_sample_rate = 0.0 # Fraction of transactions whose statements
|
|
|
|
# are logged regardless of their duration. 1.0 logs all
|
|
|
|
# statements from all transactions, 0.0 never logs.
|
|
|
|
|
2003-07-18 21:16:03 +02:00
|
|
|
# - What to Log -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2005-07-02 20:29:04 +02:00
|
|
|
#debug_print_parse = off
|
|
|
|
#debug_print_rewritten = off
|
|
|
|
#debug_print_plan = off
|
2008-08-19 20:30:04 +02:00
|
|
|
#debug_pretty_print = on
|
2007-06-30 21:12:02 +02:00
|
|
|
#log_checkpoints = off
|
2005-07-02 20:29:04 +02:00
|
|
|
#log_connections = off
|
|
|
|
#log_disconnections = off
|
|
|
|
#log_duration = off
|
2010-02-16 22:35:51 +01:00
|
|
|
#log_error_verbosity = default # terse, default, or verbose messages
|
2007-06-30 21:12:02 +02:00
|
|
|
#log_hostname = off
|
2016-10-17 22:31:13 +02:00
|
|
|
#log_line_prefix = '%m [%p] ' # special values:
|
2009-11-29 00:38:08 +01:00
|
|
|
# %a = application name
|
2005-08-19 03:55:18 +02:00
|
|
|
# %u = user name
|
|
|
|
# %d = database name
|
|
|
|
# %r = remote host and port
|
|
|
|
# %h = remote host
|
2007-12-07 17:44:56 +01:00
|
|
|
# %p = process ID
|
|
|
|
# %t = timestamp without milliseconds
|
2005-08-19 03:55:18 +02:00
|
|
|
# %m = timestamp with milliseconds
|
2015-09-07 22:46:31 +02:00
|
|
|
# %n = timestamp with milliseconds (as a Unix epoch)
|
2005-08-19 03:55:18 +02:00
|
|
|
# %i = command tag
|
2009-07-03 21:14:25 +02:00
|
|
|
# %e = SQL state
|
2007-12-07 17:44:56 +01:00
|
|
|
# %c = session ID
|
2005-08-19 03:55:18 +02:00
|
|
|
# %l = session line number
|
|
|
|
# %s = session start timestamp
|
2007-12-07 17:44:56 +01:00
|
|
|
# %v = virtual transaction ID
|
|
|
|
# %x = transaction ID (0 if none)
|
|
|
|
# %q = stop here in non-session
|
2005-08-19 03:55:18 +02:00
|
|
|
# processes
|
|
|
|
# %% = '%'
|
|
|
|
# e.g. '<%u%%%d> '
|
2007-12-07 17:44:56 +01:00
|
|
|
#log_lock_waits = off # log lock waits >= deadlock_timeout
|
2006-08-02 23:48:43 +02:00
|
|
|
#log_statement = 'none' # none, ddl, mod, all
|
2014-09-12 19:55:45 +02:00
|
|
|
#log_replication_commands = off
|
2007-12-07 17:44:56 +01:00
|
|
|
#log_temp_files = -1 # log temporary files equal or larger
|
2009-04-06 23:00:52 +02:00
|
|
|
# than the specified size in kilobytes;
|
2007-12-07 17:44:56 +01:00
|
|
|
# -1 disables, 0 logs all temp files
|
2011-09-09 23:59:11 +02:00
|
|
|
#log_timezone = 'GMT'
|
2015-10-04 17:14:28 +02:00
|
|
|
|
2017-11-16 18:57:17 +01:00
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
# PROCESS TITLE
|
|
|
|
#------------------------------------------------------------------------------
|
2015-10-04 17:14:28 +02:00
|
|
|
|
2014-06-29 14:15:09 +02:00
|
|
|
#cluster_name = '' # added to process titles if nonempty
|
|
|
|
# (change requires restart)
|
2015-10-04 17:14:28 +02:00
|
|
|
#update_process_title = on
|
2003-07-18 21:16:03 +02:00
|
|
|
|
2015-08-23 03:41:29 +02:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2017-11-16 18:57:17 +01:00
|
|
|
# STATISTICS
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-18 21:16:03 +02:00
|
|
|
|
2017-11-16 18:57:17 +01:00
|
|
|
# - Query and Index Statistics Collector -
|
2001-01-24 19:37:31 +01:00
|
|
|
|
2007-09-24 05:12:23 +02:00
|
|
|
#track_activities = on
|
|
|
|
#track_counts = on
|
2012-04-29 22:23:54 +02:00
|
|
|
#track_io_timing = off
|
2008-05-15 02:17:41 +02:00
|
|
|
#track_functions = none # none, pl, all
|
Separate multixact freezing parameters from xid's
Previously we were piggybacking on transaction ID parameters to freeze
multixacts; but since there isn't necessarily any relationship between
rates of Xid and multixact consumption, this turns out not to be a good
idea.
Therefore, we now have multixact-specific freezing parameters:
vacuum_multixact_freeze_min_age: when to remove multis as we come across
them in vacuum (default to 5 million, i.e. early in comparison to Xid's
default of 50 million)
vacuum_multixact_freeze_table_age: when to force whole-table scans
instead of scanning only the pages marked as not all visible in
visibility map (default to 150 million, same as for Xids). Whichever of
both which reaches the 150 million mark earlier will cause a whole-table
scan.
autovacuum_multixact_freeze_max_age: when for cause emergency,
uninterruptible whole-table scans (default to 400 million, double as
that for Xids). This means there shouldn't be more frequent emergency
vacuuming than previously, unless multixacts are being used very
rapidly.
Backpatch to 9.3 where multixacts were made to persist enough to require
freezing. To avoid an ABI break in 9.3, VacuumStmt has a couple of
fields in an unnatural place, and StdRdOptions is split in two so that
the newly added fields can go at the end.
Patch by me, reviewed by Robert Haas, with additional input from Andres
Freund and Tom Lane.
2014-02-13 23:30:30 +01:00
|
|
|
#track_activity_query_size = 1024 # (change requires restart)
|
2008-08-15 10:37:41 +02:00
|
|
|
#stats_temp_directory = 'pg_stat_tmp'
|
2006-06-28 00:16:44 +02:00
|
|
|
|
|
|
|
|
2017-11-16 18:57:17 +01:00
|
|
|
# - Monitoring -
|
2006-06-19 03:51:22 +02:00
|
|
|
|
|
|
|
#log_parser_stats = off
|
|
|
|
#log_planner_stats = off
|
|
|
|
#log_executor_stats = off
|
|
|
|
#log_statement_stats = off
|
|
|
|
|
2001-07-05 17:19:40 +02:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2017-11-16 18:57:17 +01:00
|
|
|
# AUTOVACUUM
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
|
2010-11-23 21:27:50 +01:00
|
|
|
#autovacuum = on # Enable autovacuum subprocess? 'on'
|
2007-12-07 17:44:56 +01:00
|
|
|
# requires track_counts to also be on.
|
|
|
|
#log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
|
|
|
|
# their durations, > 0 logs only
|
2009-04-06 23:00:52 +02:00
|
|
|
# actions running at least this number
|
|
|
|
# of milliseconds.
|
2007-12-07 17:44:56 +01:00
|
|
|
#autovacuum_max_workers = 3 # max number of autovacuum subprocesses
|
2010-09-27 15:14:14 +02:00
|
|
|
# (change requires restart)
|
2007-09-24 05:12:23 +02:00
|
|
|
#autovacuum_naptime = 1min # time between autovacuum runs
|
2007-12-07 17:44:56 +01:00
|
|
|
#autovacuum_vacuum_threshold = 50 # min number of row updates before
|
2005-08-19 03:55:18 +02:00
|
|
|
# vacuum
|
2010-11-23 21:27:50 +01:00
|
|
|
#autovacuum_analyze_threshold = 50 # min number of row updates before
|
2005-08-19 03:55:18 +02:00
|
|
|
# analyze
|
2007-12-07 17:44:56 +01:00
|
|
|
#autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum
|
|
|
|
#autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze
|
Fix recently-understood problems with handling of XID freezing, particularly
in PITR scenarios. We now WAL-log the replacement of old XIDs with
FrozenTransactionId, so that such replacement is guaranteed to propagate to
PITR slave databases. Also, rather than relying on hint-bit updates to be
preserved, pg_clog is not truncated until all instances of an XID are known to
have been replaced by FrozenTransactionId. Add new GUC variables and
pg_autovacuum columns to allow management of the freezing policy, so that
users can trade off the size of pg_clog against the amount of freezing work
done. Revise the already-existing code that forces autovacuum of tables
approaching the wraparound point to make it more bulletproof; also, revise the
autovacuum logic so that anti-wraparound vacuuming is done per-table rather
than per-database. initdb forced because of changes in pg_class, pg_database,
and pg_autovacuum catalogs. Heikki Linnakangas, Simon Riggs, and Tom Lane.
2006-11-05 23:42:10 +01:00
|
|
|
#autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum
|
|
|
|
# (change requires restart)
|
2014-05-26 05:20:15 +02:00
|
|
|
#autovacuum_multixact_freeze_max_age = 400000000 # maximum multixact age
|
Separate multixact freezing parameters from xid's
Previously we were piggybacking on transaction ID parameters to freeze
multixacts; but since there isn't necessarily any relationship between
rates of Xid and multixact consumption, this turns out not to be a good
idea.
Therefore, we now have multixact-specific freezing parameters:
vacuum_multixact_freeze_min_age: when to remove multis as we come across
them in vacuum (default to 5 million, i.e. early in comparison to Xid's
default of 50 million)
vacuum_multixact_freeze_table_age: when to force whole-table scans
instead of scanning only the pages marked as not all visible in
visibility map (default to 150 million, same as for Xids). Whichever of
both which reaches the 150 million mark earlier will cause a whole-table
scan.
autovacuum_multixact_freeze_max_age: when for cause emergency,
uninterruptible whole-table scans (default to 400 million, double as
that for Xids). This means there shouldn't be more frequent emergency
vacuuming than previously, unless multixacts are being used very
rapidly.
Backpatch to 9.3 where multixacts were made to persist enough to require
freezing. To avoid an ABI break in 9.3, VacuumStmt has a couple of
fields in an unnatural place, and StdRdOptions is split in two so that
the newly added fields can go at the end.
Patch by me, reviewed by Robert Haas, with additional input from Andres
Freund and Tom Lane.
2014-02-13 23:30:30 +01:00
|
|
|
# before forced vacuum
|
|
|
|
# (change requires restart)
|
2019-03-10 20:16:21 +01:00
|
|
|
#autovacuum_vacuum_cost_delay = 2ms # default vacuum cost delay for
|
2009-04-06 23:00:52 +02:00
|
|
|
# autovacuum, in milliseconds;
|
|
|
|
# -1 means use vacuum_cost_delay
|
2007-12-07 17:44:56 +01:00
|
|
|
#autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
|
2006-09-22 19:41:21 +02:00
|
|
|
# autovacuum, -1 means use
|
2005-08-19 03:55:18 +02:00
|
|
|
# vacuum_cost_limit
|
2005-07-14 07:13:45 +02:00
|
|
|
|
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-04 18:41:22 +02:00
|
|
|
# CLIENT CONNECTION DEFAULTS
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-18 21:16:03 +02:00
|
|
|
|
|
|
|
# - Statement Behavior -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
Disallow setting client_min_messages higher than ERROR.
Previously it was possible to set client_min_messages to FATAL or PANIC,
which had the effect of suppressing transmission of regular ERROR messages
to the client. Perhaps that seemed like a useful option in the past, but
the trouble with it is that it breaks guarantees that are explicitly made
in our FE/BE protocol spec about how a query cycle can end. While libpq
and psql manage to cope with the omission, that's mostly because they
are not very bright; client libraries that have more semantic knowledge
are likely to get confused. Notably, pgODBC doesn't behave very sanely.
Let's fix this by getting rid of the ability to set client_min_messages
above ERROR.
In HEAD, just remove the FATAL and PANIC options from the set of allowed
enum values for client_min_messages. (This change also affects
trace_recovery_messages, but that's OK since these aren't useful values
for that variable either.)
In the back branches, there was concern that rejecting these values might
break applications that are explicitly setting things that way. I'm
pretty skeptical of that argument, but accommodate it by accepting these
values and then internally setting the variable to ERROR anyway.
In all branches, this allows a couple of tiny simplifications in the
logic in elog.c, so do that.
Also respond to the point that was made that client_min_messages has
exactly nothing to do with the server's logging behavior, and therefore
does not belong in the "When To Log" subsection of the documentation.
The "Statement Behavior" subsection is a better match, so move it there.
Jonah Harris and Tom Lane
Discussion: https://postgr.es/m/7809.1541521180@sss.pgh.pa.us
Discussion: https://postgr.es/m/15479-ef0f4cc2fd995ca2@postgresql.org
2018-11-08 23:33:25 +01:00
|
|
|
#client_min_messages = notice # values in order of decreasing detail:
|
|
|
|
# debug5
|
|
|
|
# debug4
|
|
|
|
# debug3
|
|
|
|
# debug2
|
|
|
|
# debug1
|
|
|
|
# log
|
|
|
|
# notice
|
|
|
|
# warning
|
|
|
|
# error
|
2014-08-20 11:04:32 +02:00
|
|
|
#search_path = '"$user", public' # schema names
|
2018-01-19 01:12:05 +01:00
|
|
|
#row_security = on
|
2007-12-07 17:44:56 +01:00
|
|
|
#default_tablespace = '' # a tablespace name, '' uses the default
|
|
|
|
#temp_tablespaces = '' # a list of tablespace names, '' uses
|
|
|
|
# only default tablespace
|
2019-08-17 00:24:22 +02:00
|
|
|
#default_table_access_method = 'heap'
|
2005-07-02 20:29:04 +02:00
|
|
|
#check_function_bodies = on
|
2003-07-04 18:41:22 +02:00
|
|
|
#default_transaction_isolation = 'read committed'
|
2005-07-02 20:29:04 +02:00
|
|
|
#default_transaction_read_only = off
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
#default_transaction_deferrable = off
|
2008-01-27 20:12:28 +01:00
|
|
|
#session_replication_role = 'origin'
|
2009-04-06 23:00:52 +02:00
|
|
|
#statement_timeout = 0 # in milliseconds, 0 is disabled
|
2013-03-17 04:22:17 +01:00
|
|
|
#lock_timeout = 0 # in milliseconds, 0 is disabled
|
2016-10-27 03:16:20 +02:00
|
|
|
#idle_in_transaction_session_timeout = 0 # in milliseconds, 0 is disabled
|
2009-01-16 14:27:24 +01:00
|
|
|
#vacuum_freeze_min_age = 50000000
|
|
|
|
#vacuum_freeze_table_age = 150000000
|
Separate multixact freezing parameters from xid's
Previously we were piggybacking on transaction ID parameters to freeze
multixacts; but since there isn't necessarily any relationship between
rates of Xid and multixact consumption, this turns out not to be a good
idea.
Therefore, we now have multixact-specific freezing parameters:
vacuum_multixact_freeze_min_age: when to remove multis as we come across
them in vacuum (default to 5 million, i.e. early in comparison to Xid's
default of 50 million)
vacuum_multixact_freeze_table_age: when to force whole-table scans
instead of scanning only the pages marked as not all visible in
visibility map (default to 150 million, same as for Xids). Whichever of
both which reaches the 150 million mark earlier will cause a whole-table
scan.
autovacuum_multixact_freeze_max_age: when for cause emergency,
uninterruptible whole-table scans (default to 400 million, double as
that for Xids). This means there shouldn't be more frequent emergency
vacuuming than previously, unless multixacts are being used very
rapidly.
Backpatch to 9.3 where multixacts were made to persist enough to require
freezing. To avoid an ABI break in 9.3, VacuumStmt has a couple of
fields in an unnatural place, and StdRdOptions is split in two so that
the newly added fields can go at the end.
Patch by me, reviewed by Robert Haas, with additional input from Andres
Freund and Tom Lane.
2014-02-13 23:30:30 +01:00
|
|
|
#vacuum_multixact_freeze_min_age = 5000000
|
|
|
|
#vacuum_multixact_freeze_table_age = 150000000
|
2018-06-22 11:17:56 +02:00
|
|
|
#vacuum_cleanup_index_scale_factor = 0.1 # fraction of total number of tuples
|
|
|
|
# before index cleanup, 0 always performs
|
|
|
|
# index cleanup
|
2009-08-04 18:08:37 +02:00
|
|
|
#bytea_output = 'hex' # hex, escape
|
2007-01-25 12:53:52 +01:00
|
|
|
#xmlbinary = 'base64'
|
|
|
|
#xmloption = 'content'
|
2015-09-08 19:25:50 +02:00
|
|
|
#gin_fuzzy_search_limit = 0
|
2014-11-13 04:14:48 +01:00
|
|
|
#gin_pending_list_limit = 4MB
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2003-07-18 21:16:03 +02:00
|
|
|
# - Locale and Formatting -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2003-07-29 02:03:19 +02:00
|
|
|
#datestyle = 'iso, mdy'
|
2008-11-09 01:28:35 +01:00
|
|
|
#intervalstyle = 'postgres'
|
2011-09-09 23:59:11 +02:00
|
|
|
#timezone = 'GMT'
|
2007-12-07 17:44:56 +01:00
|
|
|
#timezone_abbreviations = 'Default' # Select the set of available time zone
|
|
|
|
# abbreviations. Currently, there are
|
2006-07-25 05:51:23 +02:00
|
|
|
# Default
|
Update time zone data files to tzdata release 2014h.
Most zones in the Russian Federation are subtracting one or two hours
as of 2014-10-26. Update the meanings of the abbreviations IRKT, KRAT,
MAGT, MSK, NOVT, OMST, SAKT, VLAT, YAKT, YEKT to match.
The IANA timezone database has adopted abbreviations of the form AxST/AxDT
for all Australian time zones, reflecting what they believe to be current
majority practice Down Under. These names do not conflict with usage
elsewhere (other than ACST for Acre Summer Time, which has been in disuse
since 1994). Accordingly, adopt these names into our "Default" timezone
abbreviation set. The "Australia" abbreviation set now contains only
CST,EAST,EST,SAST,SAT,WST, all of which are thought to be mostly historical
usage. Note that SAST has also been changed to be South Africa Standard
Time in the "Default" abbreviation set.
Add zone abbreviations SRET (Asia/Srednekolymsk) and XJT (Asia/Urumqi),
and use WSST/WSDT for western Samoa.
Also a DST law change in the Turks & Caicos Islands (America/Grand_Turk),
and numerous corrections for historical time zone data.
2014-10-04 20:18:19 +02:00
|
|
|
# Australia (historical usage)
|
2006-07-25 05:51:23 +02:00
|
|
|
# India
|
2007-12-07 17:44:56 +01:00
|
|
|
# You can create your own file in
|
|
|
|
# share/timezonesets/.
|
Change floating-point output format for improved performance.
Previously, floating-point output was done by rounding to a specific
decimal precision; by default, to 6 or 15 decimal digits (losing
information) or as requested using extra_float_digits. Drivers that
wanted exact float values, and applications like pg_dump that must
preserve values exactly, set extra_float_digits=3 (or sometimes 2 for
historical reasons, though this isn't enough for float4).
Unfortunately, decimal rounded output is slow enough to become a
noticable bottleneck when dealing with large result sets or COPY of
large tables when many floating-point values are involved.
Floating-point output can be done much faster when the output is not
rounded to a specific decimal length, but rather is chosen as the
shortest decimal representation that is closer to the original float
value than to any other value representable in the same precision. The
recently published Ryu algorithm by Ulf Adams is both relatively
simple and remarkably fast.
Accordingly, change float4out/float8out to output shortest decimal
representations if extra_float_digits is greater than 0, and make that
the new default. Applications that need rounded output can set
extra_float_digits back to 0 or below, and take the resulting
performance hit.
We make one concession to portability for systems with buggy
floating-point input: we do not output decimal values that fall
exactly halfway between adjacent representable binary values (which
would rely on the reader doing round-to-nearest-even correctly). This
is known to be a problem at least for VS2013 on Windows.
Our version of the Ryu code originates from
https://github.com/ulfjack/ryu/ at commit c9c3fb1979, but with the
following (significant) modifications:
- Output format is changed to use fixed-point notation for small
exponents, as printf would, and also to use lowercase 'e', a
minimum of 2 exponent digits, and a mandatory sign on the exponent,
to keep the formatting as close as possible to previous output.
- The output of exact midpoint values is disabled as noted above.
- The integer fast-path code is changed somewhat (since we have
fixed-point output and the upstream did not).
- Our project style has been largely applied to the code with the
exception of C99 declaration-after-statement, which has been
retained as an exception to our present policy.
- Most of upstream's debugging and conditionals are removed, and we
use our own configure tests to determine things like uint128
availability.
Changing the float output format obviously affects a number of
regression tests. This patch uses an explicit setting of
extra_float_digits=0 for test output that is not expected to be
exactly reproducible (e.g. due to numerical instability or differing
algorithms for transcendental functions).
Conversions from floats to numeric are unchanged by this patch. These
may appear in index expressions and it is not yet clear whether any
change should be made, so that can be left for another day.
This patch assumes that the only supported floating point format is
now IEEE format, and the documentation is updated to reflect that.
Code by me, adapting the work of Ulf Adams and other contributors.
References:
https://dl.acm.org/citation.cfm?id=3192369
Reviewed-by: Tom Lane, Andres Freund, Donald Dong
Discussion: https://postgr.es/m/87r2el1bx6.fsf@news-spur.riddles.org.uk
2019-02-13 16:20:33 +01:00
|
|
|
#extra_float_digits = 1 # min -15, max 3; any value >0 actually
|
|
|
|
# selects precise output mode
|
2005-08-19 03:55:18 +02:00
|
|
|
#client_encoding = sql_ascii # actually, defaults to database
|
|
|
|
# encoding
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
# These settings are initialized by initdb, but they can be changed.
|
|
|
|
#lc_messages = 'C' # locale for system error message
|
2005-08-19 03:55:18 +02:00
|
|
|
# strings
|
|
|
|
#lc_monetary = 'C' # locale for monetary formatting
|
|
|
|
#lc_numeric = 'C' # locale for number formatting
|
|
|
|
#lc_time = 'C' # locale for time formatting
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2007-08-21 03:11:32 +02:00
|
|
|
# default configuration for text search
|
|
|
|
#default_text_search_config = 'pg_catalog.simple'
|
|
|
|
|
2017-11-16 18:57:17 +01:00
|
|
|
# - Shared Library Preloading -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2017-11-16 18:57:17 +01:00
|
|
|
#shared_preload_libraries = '' # (change requires restart)
|
2006-08-15 20:26:59 +02:00
|
|
|
#local_preload_libraries = ''
|
2013-11-26 06:00:37 +01:00
|
|
|
#session_preload_libraries = ''
|
2018-09-15 23:24:35 +02:00
|
|
|
#jit_provider = 'llvmjit' # JIT library to use
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2017-11-16 18:57:17 +01:00
|
|
|
# - Other Defaults -
|
|
|
|
|
|
|
|
#dynamic_library_path = '$libdir'
|
|
|
|
|
2003-07-18 21:16:03 +02:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-04 18:41:22 +02:00
|
|
|
# LOCK MANAGEMENT
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2006-09-22 19:41:21 +02:00
|
|
|
#deadlock_timeout = 1s
|
2005-08-30 02:58:48 +02:00
|
|
|
#max_locks_per_transaction = 64 # min 10
|
2006-07-24 12:44:40 +02:00
|
|
|
# (change requires restart)
|
2011-02-15 14:00:04 +01:00
|
|
|
#max_pred_locks_per_transaction = 64 # min 10
|
Implement genuine serializable isolation level.
Until now, our Serializable mode has in fact been what's called Snapshot
Isolation, which allows some anomalies that could not occur in any
serialized ordering of the transactions. This patch fixes that using a
method called Serializable Snapshot Isolation, based on research papers by
Michael J. Cahill (see README-SSI for full references). In Serializable
Snapshot Isolation, transactions run like they do in Snapshot Isolation,
but a predicate lock manager observes the reads and writes performed and
aborts transactions if it detects that an anomaly might occur. This method
produces some false positives, ie. it sometimes aborts transactions even
though there is no anomaly.
To track reads we implement predicate locking, see storage/lmgr/predicate.c.
Whenever a tuple is read, a predicate lock is acquired on the tuple. Shared
memory is finite, so when a transaction takes many tuple-level locks on a
page, the locks are promoted to a single page-level lock, and further to a
single relation level lock if necessary. To lock key values with no matching
tuple, a sequential scan always takes a relation-level lock, and an index
scan acquires a page-level lock that covers the search key, whether or not
there are any matching keys at the moment.
A predicate lock doesn't conflict with any regular locks or with another
predicate locks in the normal sense. They're only used by the predicate lock
manager to detect the danger of anomalies. Only serializable transactions
participate in predicate locking, so there should be no extra overhead for
for other transactions.
Predicate locks can't be released at commit, but must be remembered until
all the transactions that overlapped with it have completed. That means that
we need to remember an unbounded amount of predicate locks, so we apply a
lossy but conservative method of tracking locks for committed transactions.
If we run short of shared memory, we overflow to a new "pg_serial" SLRU
pool.
We don't currently allow Serializable transactions in Hot Standby mode.
That would be hard, because even read-only transactions can cause anomalies
that wouldn't otherwise occur.
Serializable isolation mode now means the new fully serializable level.
Repeatable Read gives you the old Snapshot Isolation level that we have
always had.
Kevin Grittner and Dan Ports, reviewed by Jeff Davis, Heikki Linnakangas and
Anssi Kääriäinen
2011-02-07 22:46:51 +01:00
|
|
|
# (change requires restart)
|
2017-04-08 04:38:05 +02:00
|
|
|
#max_pred_locks_per_relation = -2 # negative values mean
|
|
|
|
# (max_pred_locks_per_transaction
|
|
|
|
# / -max_pred_locks_per_relation) - 1
|
|
|
|
#max_pred_locks_per_page = 2 # min 0
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2012-05-14 03:14:35 +02:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2017-11-16 18:57:17 +01:00
|
|
|
# VERSION AND PLATFORM COMPATIBILITY
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2003-07-18 21:16:03 +02:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
# - Previous PostgreSQL Versions -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2005-11-17 23:14:56 +01:00
|
|
|
#array_nulls = on
|
2006-05-21 22:10:42 +02:00
|
|
|
#backslash_quote = safe_encoding # on, off, or safe_encoding
|
2006-05-11 21:15:36 +02:00
|
|
|
#escape_string_warning = on
|
2009-12-11 04:34:57 +01:00
|
|
|
#lo_compat_privileges = off
|
Make operator precedence follow the SQL standard more closely.
While the SQL standard is pretty vague on the overall topic of operator
precedence (because it never presents a unified BNF for all expressions),
it does seem reasonable to conclude from the spec for <boolean value
expression> that OR has the lowest precedence, then AND, then NOT, then IS
tests, then the six standard comparison operators, then everything else
(since any non-boolean operator in a WHERE clause would need to be an
argument of one of these).
We were only sort of on board with that: most notably, while "<" ">" and
"=" had properly low precedence, "<=" ">=" and "<>" were treated as generic
operators and so had significantly higher precedence. And "IS" tests were
even higher precedence than those, which is very clearly wrong per spec.
Another problem was that "foo NOT SOMETHING bar" constructs, such as
"x NOT LIKE y", were treated inconsistently because of a bison
implementation artifact: they had the documented precedence with respect
to operators to their right, but behaved like NOT (i.e., very low priority)
with respect to operators to their left.
Fixing the precedence issues is just a small matter of rearranging the
precedence declarations in gram.y, except for the NOT problem, which
requires adding an additional lookahead case in base_yylex() so that we
can attach a different token precedence to NOT LIKE and allied two-word
operators.
The bulk of this patch is not the bug fix per se, but adding logic to
parse_expr.c to allow giving warnings if an expression has changed meaning
because of these precedence changes. These warnings are off by default
and are enabled by the new GUC operator_precedence_warning. It's believed
that very few applications will be affected by these changes, but it was
agreed that a warning mechanism is essential to help debug any that are.
2015-03-11 18:22:52 +01:00
|
|
|
#operator_precedence_warning = off
|
2010-07-22 03:22:35 +02:00
|
|
|
#quote_all_identifiers = off
|
2010-07-20 02:34:44 +02:00
|
|
|
#standard_conforming_strings = on
|
2008-01-30 19:35:55 +01:00
|
|
|
#synchronize_seqscans = on
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
# - Other Platforms and Clients -
|
2003-07-04 18:41:22 +02:00
|
|
|
|
2005-07-02 20:29:04 +02:00
|
|
|
#transform_null_equals = off
|
2005-08-21 05:39:37 +02:00
|
|
|
|
|
|
|
|
2010-07-20 02:47:53 +02:00
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
# ERROR HANDLING
|
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
|
2012-01-24 16:40:47 +01:00
|
|
|
#exit_on_error = off # terminate session on any error?
|
|
|
|
#restart_after_crash = on # reinitialize after backend crash?
|
2019-02-28 03:02:11 +01:00
|
|
|
#data_sync_retry = off # retry or panic on failure to fsync
|
|
|
|
# data?
|
|
|
|
# (change requires restart)
|
2010-07-20 02:47:53 +02:00
|
|
|
|
2013-05-30 04:00:13 +02:00
|
|
|
|
2012-09-24 16:55:53 +02:00
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
# CONFIG FILE INCLUDES
|
|
|
|
#------------------------------------------------------------------------------
|
|
|
|
|
|
|
|
# These options allow settings to be loaded from files other than the
|
Reject empty names and recursion in config-file include directives.
An empty file name or subdirectory name leads join_path_components() to
just produce the parent directory name, which leads to weird failures or
recursive inclusions. Let's throw a specific error for that. It takes
only slightly more code to detect all-blank names, so do so.
Also, detect direct recursion, ie a file calling itself. As coded
this will also detect recursion via "include_dir '.'", which is
perhaps more likely than explicitly including the file itself.
Detecting indirect recursion would require API changes for guc-file.l
functions, which seems not worth it since extensions might call them.
The nesting depth limit will catch such cases eventually, just not
with such an on-point error message.
In passing, adjust the example usages in postgresql.conf.sample
to perhaps eliminate the problem at the source: there's no reason
for the examples to suggest that an empty value is valid.
Per a trouble report from Brent Bates. Back-patch to 9.5; the
issue is old, but the code in 9.4 is enough different that the
patch doesn't apply easily, and it doesn't seem worth the trouble
to fix there.
Ian Barwick and Tom Lane
Discussion: https://postgr.es/m/8c8bcbca-3bd9-dc6e-8986-04a5abdef142@2ndquadrant.com
2019-08-27 20:44:26 +02:00
|
|
|
# default postgresql.conf. Note that these are directives, not variable
|
|
|
|
# assignments, so they can usefully be given more than once.
|
2012-09-24 16:55:53 +02:00
|
|
|
|
Reject empty names and recursion in config-file include directives.
An empty file name or subdirectory name leads join_path_components() to
just produce the parent directory name, which leads to weird failures or
recursive inclusions. Let's throw a specific error for that. It takes
only slightly more code to detect all-blank names, so do so.
Also, detect direct recursion, ie a file calling itself. As coded
this will also detect recursion via "include_dir '.'", which is
perhaps more likely than explicitly including the file itself.
Detecting indirect recursion would require API changes for guc-file.l
functions, which seems not worth it since extensions might call them.
The nesting depth limit will catch such cases eventually, just not
with such an on-point error message.
In passing, adjust the example usages in postgresql.conf.sample
to perhaps eliminate the problem at the source: there's no reason
for the examples to suggest that an empty value is valid.
Per a trouble report from Brent Bates. Back-patch to 9.5; the
issue is old, but the code in 9.4 is enough different that the
patch doesn't apply easily, and it doesn't seem worth the trouble
to fix there.
Ian Barwick and Tom Lane
Discussion: https://postgr.es/m/8c8bcbca-3bd9-dc6e-8986-04a5abdef142@2ndquadrant.com
2019-08-27 20:44:26 +02:00
|
|
|
#include_dir = '...' # include files ending in '.conf' from
|
2019-04-18 00:12:10 +02:00
|
|
|
# a directory, e.g., 'conf.d'
|
Reject empty names and recursion in config-file include directives.
An empty file name or subdirectory name leads join_path_components() to
just produce the parent directory name, which leads to weird failures or
recursive inclusions. Let's throw a specific error for that. It takes
only slightly more code to detect all-blank names, so do so.
Also, detect direct recursion, ie a file calling itself. As coded
this will also detect recursion via "include_dir '.'", which is
perhaps more likely than explicitly including the file itself.
Detecting indirect recursion would require API changes for guc-file.l
functions, which seems not worth it since extensions might call them.
The nesting depth limit will catch such cases eventually, just not
with such an on-point error message.
In passing, adjust the example usages in postgresql.conf.sample
to perhaps eliminate the problem at the source: there's no reason
for the examples to suggest that an empty value is valid.
Per a trouble report from Brent Bates. Back-patch to 9.5; the
issue is old, but the code in 9.4 is enough different that the
patch doesn't apply easily, and it doesn't seem worth the trouble
to fix there.
Ian Barwick and Tom Lane
Discussion: https://postgr.es/m/8c8bcbca-3bd9-dc6e-8986-04a5abdef142@2ndquadrant.com
2019-08-27 20:44:26 +02:00
|
|
|
#include_if_exists = '...' # include file only if it exists
|
|
|
|
#include = '...' # include file
|
2010-07-20 02:47:53 +02:00
|
|
|
|
2013-05-30 04:00:13 +02:00
|
|
|
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2005-08-21 05:39:37 +02:00
|
|
|
# CUSTOMIZED OPTIONS
|
2007-12-07 17:44:56 +01:00
|
|
|
#------------------------------------------------------------------------------
|
2005-08-21 05:39:37 +02:00
|
|
|
|
2011-10-04 18:36:18 +02:00
|
|
|
# Add settings for extensions here
|