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
|
|
|
#
|
2021-07-21 16:17:07 +02:00
|
|
|
# Memory units: B = bytes Time units: us = microseconds
|
|
|
|
# kB = kilobytes ms = milliseconds
|
2009-04-06 21:03:04 +02:00
|
|
|
# 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
|
|
|
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#client_connection_check_interval = 0 # time between checks for client
|
|
|
|
# disconnection while running queries;
|
|
|
|
# 0 for never
|
|
|
|
|
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
|
2020-06-10 16:16:37 +02:00
|
|
|
#password_encryption = scram-sha-256 # scram-sha-256 or md5
|
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
|
Fix up usage of krb_server_keyfile GUC parameter.
secure_open_gssapi() installed the krb_server_keyfile setting as
KRB5_KTNAME unconditionally, so long as it's not empty. However,
pg_GSS_recvauth() only installed it if KRB5_KTNAME wasn't set already,
leading to a troubling inconsistency: in theory, clients could see
different sets of server principal names depending on whether they
use GSSAPI encryption. Always using krb_server_keyfile seems like
the right thing, so make both places do that. Also fix up
secure_open_gssapi()'s lack of a check for setenv() failure ---
it's unlikely, surely, but security-critical actions are no place
to be sloppy.
Also improve the associated documentation.
This patch does nothing about secure_open_gssapi()'s use of setenv(),
and indeed causes pg_GSS_recvauth() to use it too. That's nominally
against project portability rules, but since this code is only built
with --with-gssapi, I do not feel a need to do something about this
in the back branches. A fix will be forthcoming for HEAD though.
Back-patch to v12 where GSSAPI encryption was introduced. The
dubious behavior in pg_GSS_recvauth() goes back further, but it
didn't have anything to be inconsistent with, so let it be.
Discussion: https://postgr.es/m/2187460.1609263156@sss.pgh.pa.us
2020-12-30 17:38:42 +01:00
|
|
|
#krb_server_keyfile = 'FILE:${sysconfdir}/krb5.keytab'
|
2009-01-02 12:26:24 +01:00
|
|
|
#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 = ''
|
2021-02-18 07:59:10 +01:00
|
|
|
#ssl_crl_dir = ''
|
2018-01-19 01:12:05 +01:00
|
|
|
#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
|
|
|
|
2021-08-23 18:33:38 +02:00
|
|
|
#shared_buffers = 128MB # 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)
|
2020-07-17 04:33:00 +02:00
|
|
|
#huge_page_size = 0 # zero for system default
|
|
|
|
# (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
|
2022-02-17 03:41:52 +01:00
|
|
|
#hash_mem_multiplier = 2.0 # 1-1000.0 multiplier on hash table work_mem
|
2014-02-24 19:04:51 +01:00
|
|
|
#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)
|
2020-07-31 07:27:09 +02:00
|
|
|
#min_dynamic_shared_memory = 0MB # (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
|
2020-05-28 08:39:05 +02:00
|
|
|
# in kilobytes, or -1 for no limit
|
2011-07-17 20:19:31 +02:00
|
|
|
|
2018-06-04 21:34:42 +02:00
|
|
|
# - Kernel Resources -
|
2001-06-28 01:31:40 +02:00
|
|
|
|
Account explicitly for long-lived FDs that are allocated outside fd.c.
The comments in fd.c have long claimed that all file allocations should
go through that module, but in reality that's not always practical.
fd.c doesn't supply APIs for invoking some FD-producing syscalls like
pipe() or epoll_create(); and the APIs it does supply for non-virtual
FDs are mostly insistent on releasing those FDs at transaction end;
and in some cases the actual open() call is in code that can't be made
to use fd.c, such as libpq.
This has led to a situation where, in a modern server, there are likely
to be seven or so long-lived FDs per backend process that are not known
to fd.c. Since NUM_RESERVED_FDS is only 10, that meant we had *very*
few spare FDs if max_files_per_process is >= the system ulimit and
fd.c had opened all the files it thought it safely could. The
contrib/postgres_fdw regression test, in particular, could easily be
made to fall over by running it under a restrictive ulimit.
To improve matters, invent functions Acquire/Reserve/ReleaseExternalFD
that allow outside callers to tell fd.c that they have or want to allocate
a FD that's not directly managed by fd.c. Add calls to track all the
fixed FDs in a standard backend session, so that we are honestly
guaranteeing that NUM_RESERVED_FDS FDs remain unused below the EMFILE
limit in a backend's idle state. The coding rules for these functions say
that there's no need to call them in code that just allocates one FD over
a fairly short interval; we can dip into NUM_RESERVED_FDS for such cases.
That means that there aren't all that many places where we need to worry.
But postgres_fdw and dblink must use this facility to account for
long-lived FDs consumed by libpq connections. There may be other places
where it's worth doing such accounting, too, but this seems like enough
to solve the immediate problem.
Internally to fd.c, "external" FDs are limited to max_safe_fds/3 FDs.
(Callers can choose to ignore this limit, but of course it's unwise
to do so except for fixed file allocations.) I also reduced the limit
on "allocated" files to max_safe_fds/3 FDs (it had been max_safe_fds/2).
Conceivably a smarter rule could be used here --- but in practice,
on reasonable systems, max_safe_fds should be large enough that this
isn't much of an issue, so KISS for now. To avoid possible regression
in the number of external or allocated files that can be opened,
increase FD_MINFREE and the lower limit on max_files_per_process a
little bit; we now insist that the effective "ulimit -n" be at least 64.
This seems like pretty clearly a bug fix, but in view of the lack of
field complaints, I'll refrain from risking a back-patch.
Discussion: https://postgr.es/m/E1izCmM-0005pV-Co@gemulon.postgresql.org
2020-02-24 23:28:33 +01:00
|
|
|
#max_files_per_process = 1000 # min 64
|
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
|
2021-01-28 00:11:13 +01:00
|
|
|
#vacuum_cost_page_miss = 2 # 0-10000 credits
|
2005-08-19 03:55:18 +02:00
|
|
|
#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 -
|
|
|
|
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#backend_flush_after = 0 # measured in pages, 0 disables
|
2012-05-14 03:14:35 +02:00
|
|
|
#effective_io_concurrency = 1 # 1-1000; 0 disables prefetching
|
2020-04-02 05:44:11 +02:00
|
|
|
#maintenance_io_concurrency = 10 # 1-1000; 0 disables prefetching
|
2016-12-05 16:53:21 +01:00
|
|
|
#max_worker_processes = 8 # (change requires restart)
|
2017-03-07 21:30:03 +01:00
|
|
|
#max_parallel_workers_per_gather = 2 # taken from max_parallel_workers
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#max_parallel_maintenance_workers = 2 # taken from max_parallel_workers
|
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
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#parallel_leader_participation = on
|
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)
|
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
|
2021-02-15 03:43:39 +01:00
|
|
|
# fdatasync (default on Linux and FreeBSD)
|
2005-08-19 03:55:18 +02:00
|
|
|
# fsync
|
|
|
|
# fsync_writethrough
|
|
|
|
# open_sync
|
|
|
|
#full_page_writes = on # recover from partial 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)
|
Add support for LZ4 with compression of full-page writes in WAL
The logic is implemented so as there can be a choice in the compression
used when building a WAL record, and an extra per-record bit is used to
track down if a block is compressed with PGLZ, LZ4 or nothing.
wal_compression, the existing parameter, is changed to an enum with
support for the following backward-compatible values:
- "off", the default, to not use compression.
- "pglz" or "on", to compress FPWs with PGLZ.
- "lz4", the new mode, to compress FPWs with LZ4.
Benchmarking has showed that LZ4 outclasses easily PGLZ. ZSTD would be
also an interesting choice, but going just with LZ4 for now makes the
patch minimalistic as toast compression is already able to use LZ4, so
there is no need to worry about any build-related needs for this
implementation.
Author: Andrey Borodin, Justin Pryzby
Reviewed-by: Dilip Kumar, Michael Paquier
Discussion: https://postgr.es/m/3037310D-ECB7-4BF1-AF20-01C10BB33A33@yandex-team.ru
2021-06-29 04:17:55 +02:00
|
|
|
#wal_compression = off # enables compression of full-page writes;
|
Add support for zstd with compression of full-page writes in WAL
wal_compression gains a new value, "zstd", to allow the compression of
full-page images using the compression method of the same name.
Compression is done using the default level recommended by the library,
as of ZSTD_CLEVEL_DEFAULT = 3. Some benchmarking has shown that it
could make sense to use a level lower for the FPI compression, like 1 or
2, as the compression rate did not change much with a bit less CPU
consumed, but any tests done would only cover few scenarios so it is
hard to come to a clear conclusion. Anyway, there is no reason to not
use the default level instead, which is the level recommended by the
library so it should be fine for most cases.
zstd outclasses easily pglz, and is better than LZ4 where one wants to
have more compression at the cost of extra CPU but both are good enough
in their own scenarios, so the choice between one or the other of these
comes to a study of the workload patterns and the schema involved,
mainly.
This commit relies heavily on 4035cd5, that reshaped the code creating
and restoring full-page writes to be aware of the compression type,
making this integration straight-forward.
This patch borrows some early work from Andrey Borodin, though the patch
got a complete rewrite.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20220222231948.GJ9008@telsasoft.com
2022-03-11 04:18:53 +01:00
|
|
|
# off, pglz, lz4, zstd, or on
|
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
|
Skip WAL for new relfilenodes, under wal_level=minimal.
Until now, only selected bulk operations (e.g. COPY) did this. If a
given relfilenode received both a WAL-skipping COPY and a WAL-logged
operation (e.g. INSERT), recovery could lose tuples from the COPY. See
src/backend/access/transam/README section "Skipping WAL for New
RelFileNode" for the new coding rules. Maintainers of table access
methods should examine that section.
To maintain data durability, just before commit, we choose between an
fsync of the relfilenode and copying its contents to WAL. A new GUC,
wal_skip_threshold, guides that choice. If this change slows a workload
that creates small, permanent relfilenodes under wal_level=minimal, try
adjusting wal_skip_threshold. Users setting a timeout on COMMIT may
need to adjust that timeout, and log_min_duration_statement analysis
will reflect time consumption moving to COMMIT from commands like COPY.
Internally, this requires a reliable determination of whether
RollbackAndReleaseCurrentSubTransaction() would unlink a relation's
current relfilenode. Introduce rd_firstRelfilenodeSubid. Amend the
specification of rd_createSubid such that the field is zero when a new
rel has an old rd_node. Make relcache.c retain entries for certain
dropped relations until end of transaction.
Bump XLOG_PAGE_MAGIC, since this introduces XLOG_GIST_ASSIGN_LSN.
Future servers accept older WAL, so this bump is discretionary.
Kyotaro Horiguchi, reviewed (in earlier, similar versions) by Robert
Haas. Heikki Linnakangas and Michael Paquier implemented earlier
designs that materially clarified the problem. Reviewed, in earlier
designs, by Andrew Dunstan, Andres Freund, Alvaro Herrera, Tom Lane,
Fujii Masao, and Simon Riggs. Reported by Martijn van Oosterhout.
Discussion: https://postgr.es/m/20150702220524.GA9392@svana.org
2020-04-04 21:25:34 +02:00
|
|
|
#wal_skip_threshold = 2MB
|
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
|
2021-03-24 18:07:51 +01:00
|
|
|
#checkpoint_completion_target = 0.9 # 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
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#max_wal_size = 1GB
|
|
|
|
#min_wal_size = 80MB
|
2021-04-08 13:03:43 +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)
|
2022-02-03 19:57:27 +01:00
|
|
|
#archive_library = '' # library to use to archive a logfile segment
|
|
|
|
# (empty string indicates archive_command should
|
|
|
|
# be used)
|
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'
|
|
|
|
#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
|
|
|
|
2020-06-14 23:05:18 +02:00
|
|
|
# Set these on the primary 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)
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#max_replication_slots = 10 # max number of replication slots
|
|
|
|
# (change requires restart)
|
2020-07-20 06:30:18 +02:00
|
|
|
#wal_keep_size = 0 # in megabytes; 0 disables
|
2020-05-28 08:39:05 +02:00
|
|
|
#max_slot_wal_keep_size = -1 # in megabytes; -1 disables
|
2012-10-11 16:39:52 +02:00
|
|
|
#wal_sender_timeout = 60s # in milliseconds; 0 disables
|
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
|
|
|
|
2020-06-14 23:05:18 +02:00
|
|
|
# - Primary Server -
|
2011-07-19 09:59:55 +02:00
|
|
|
|
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
|
|
|
|
2020-06-14 23:05:18 +02:00
|
|
|
# These settings are ignored on a primary server.
|
2011-07-07 21:10:32 +02:00
|
|
|
|
2018-11-25 16:31:16 +01:00
|
|
|
#primary_conninfo = '' # connection string to sending server
|
|
|
|
#primary_slot_name = '' # replication slot on sending server
|
|
|
|
#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
|
2020-06-07 14:35:12 +02:00
|
|
|
#wal_receiver_create_temp_slot = off # create temp slot if primary_slot_name
|
|
|
|
# is not set
|
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
|
2020-06-14 23:05:18 +02:00
|
|
|
# communication from primary
|
2012-10-11 16:39:52 +02:00
|
|
|
# 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
|
|
|
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#enable_async_append = on
|
2005-07-02 20:29:04 +02:00
|
|
|
#enable_bitmapscan = on
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#enable_gathermerge = on
|
2005-07-02 20:29:04 +02:00
|
|
|
#enable_hashagg = on
|
|
|
|
#enable_hashjoin = on
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#enable_incremental_sort = on
|
2005-07-02 20:29:04 +02:00
|
|
|
#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
|
2021-07-14 02:43:58 +02:00
|
|
|
#enable_memoize = 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
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#enable_parallel_hash = on
|
|
|
|
#enable_partition_pruning = on
|
|
|
|
#enable_partitionwise_join = off
|
|
|
|
#enable_partitionwise_aggregate = off
|
2005-07-02 20:29:04 +02:00
|
|
|
#enable_seqscan = on
|
|
|
|
#enable_sort = on
|
|
|
|
#enable_tidscan = 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_setup_cost = 1000.0 # same scale as above
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#parallel_tuple_cost = 0.1 # same scale as above
|
|
|
|
#min_parallel_table_scan_size = 8MB
|
|
|
|
#min_parallel_index_scan_size = 512kB
|
|
|
|
#effective_cache_size = 4GB
|
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
|
|
|
|
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
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#jit = on # allow JIT compilation
|
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
|
2018-08-22 11:28:39 +02:00
|
|
|
#plan_cache_mode = auto # auto, force_generic_plan or
|
|
|
|
# force_custom_plan
|
2022-03-24 16:47:41 +01:00
|
|
|
#recursive_worktable_factor = 10.0 # range 0.001-1000000
|
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
|
Introduce log_destination=jsonlog
"jsonlog" is a new value that can be added to log_destination to provide
logs in the JSON format, with its output written to a file, making it
the third type of destination of this kind, after "stderr" and
"csvlog". The format is convenient to feed logs to other applications.
There is also a plugin external to core that provided this feature using
the hook in elog.c, but this had to overwrite the output of "stderr" to
work, so being able to do both at the same time was not possible. The
files generated by this log format are suffixed with ".json", and use
the same rotation policies as the other two formats depending on the
backend configuration.
This takes advantage of the refactoring work done previously in ac7c807,
bed6ed3, 8b76f89 and 2d77d83 for the backend parts, and 72b76f7 for the
TAP tests, making the addition of any new file-based format rather
straight-forward.
The documentation is updated to list all the keys and the values that
can exist in this new format. pg_current_logfile() also required a
refresh for the new option.
Author: Sehrope Sarkuni, Michael Paquier
Reviewed-by: Nathan Bossart, Justin Pryzby
Discussion: https://postgr.es/m/CAH7T-aqswBM6JWe4pDehi1uOiufqe06DJWaU5=X7dDLyqUExHg@mail.gmail.com
2022-01-17 02:16:53 +01:00
|
|
|
# stderr, csvlog, jsonlog, syslog, and
|
|
|
|
# eventlog, depending on platform.
|
|
|
|
# csvlog and jsonlog require
|
|
|
|
# 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:
|
Introduce log_destination=jsonlog
"jsonlog" is a new value that can be added to log_destination to provide
logs in the JSON format, with its output written to a file, making it
the third type of destination of this kind, after "stderr" and
"csvlog". The format is convenient to feed logs to other applications.
There is also a plugin external to core that provided this feature using
the hook in elog.c, but this had to overwrite the output of "stderr" to
work, so being able to do both at the same time was not possible. The
files generated by this log format are suffixed with ".json", and use
the same rotation policies as the other two formats depending on the
backend configuration.
This takes advantage of the refactoring work done previously in ac7c807,
bed6ed3, 8b76f89 and 2d77d83 for the backend parts, and 72b76f7 for the
TAP tests, making the addition of any new file-based format rather
straight-forward.
The documentation is updated to list all the keys and the values that
can exist in this new format. pg_current_logfile() also required a
refresh for the new option.
Author: Sehrope Sarkuni, Michael Paquier
Reviewed-by: Nathan Bossart, Justin Pryzby
Discussion: https://postgr.es/m/CAH7T-aqswBM6JWe4pDehi1uOiufqe06DJWaU5=X7dDLyqUExHg@mail.gmail.com
2022-01-17 02:16:53 +01:00
|
|
|
#logging_collector = off # Enable capturing of stderr, jsonlog
|
|
|
|
# and csvlog into log files. Required
|
|
|
|
# to be on for csvlogs and jsonlogs.
|
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
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#log_rotation_age = 1d # Automatic rotation of logfiles will
|
|
|
|
# happen after that time. 0 disables.
|
|
|
|
#log_rotation_size = 10MB # Automatic rotation of logfiles will
|
|
|
|
# happen after that much log output.
|
|
|
|
# 0 disables.
|
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.
|
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
|
|
|
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
# This is only relevant when logging to eventlog (Windows):
|
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
|
|
|
|
2020-06-07 14:35:12 +02:00
|
|
|
#log_min_duration_sample = -1 # -1 is disabled, 0 logs a sample of statements
|
2019-11-04 01:57:45 +01:00
|
|
|
# and their durations, > 0 logs only a sample of
|
|
|
|
# statements running at least this number
|
2020-06-07 14:35:12 +02:00
|
|
|
# of milliseconds;
|
|
|
|
# sample fraction is determined by log_statement_sample_rate
|
2019-11-04 01:57:45 +01:00
|
|
|
|
2020-06-07 14:35:12 +02:00
|
|
|
#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-11-04 01:57:45 +01:00
|
|
|
|
|
|
|
|
2020-06-07 14:35:12 +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
|
2019-04-03 23:43:59 +02:00
|
|
|
|
Report progress of startup operations that take a long time.
Users sometimes get concerned whe they start the server and it
emits a few messages and then doesn't emit any more messages for
a long time. Generally, what's happening is either that the
system is taking a long time to apply WAL, or it's taking a
long time to reset unlogged relations, or it's taking a long
time to fsync the data directory, but it's not easy to tell
which is the case.
To fix that, add a new 'log_startup_progress_interval' setting,
by default 10s. When an operation that is known to be potentially
long-running takes more than this amount of time, we'll log a
status update each time this interval elapses.
To avoid undesirable log chatter, don't log anything about WAL
replay when in standby mode.
Nitin Jadhav and Robert Haas, reviewed by Amul Sul, Bharath
Rupireddy, Justin Pryzby, Michael Paquier, and Álvaro Herrera.
Discussion: https://postgr.es/m/CA+TgmoaHQrgDFOBwgY16XCoMtXxsrVGFB2jNCvb7-ubuEe1MGg@mail.gmail.com
Discussion: https://postgr.es/m/CAMm1aWaHF7VE69572_OLQ+MgpT5RUiUDgF1x5RrtkJBLdpRj3Q@mail.gmail.com
2021-10-25 17:51:57 +02:00
|
|
|
#log_startup_progress_interval = 10s # Time between progress updates for
|
|
|
|
# long-running startup operations.
|
|
|
|
# 0 disables the feature, > 0 indicates
|
|
|
|
# the interval in milliseconds.
|
|
|
|
|
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
|
2021-12-13 15:48:04 +01:00
|
|
|
#log_autovacuum_min_duration = 10min # log autovacuum activity;
|
2021-04-12 06:53:17 +02:00
|
|
|
# -1 disables, 0 logs all actions and
|
|
|
|
# their durations, > 0 logs only
|
|
|
|
# actions running at least this number
|
|
|
|
# of milliseconds.
|
2021-12-13 15:48:04 +01:00
|
|
|
#log_checkpoints = on
|
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
|
2020-03-15 11:20:21 +01:00
|
|
|
# %b = backend type
|
2007-12-07 17:44:56 +01:00
|
|
|
# %p = process ID
|
2020-08-03 06:38:48 +02:00
|
|
|
# %P = process ID of parallel group leader
|
2007-12-07 17:44:56 +01:00
|
|
|
# %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)
|
Make use of in-core query id added by commit 5fd9dfa5f5
Use the in-core query id computation for pg_stat_activity,
log_line_prefix, and EXPLAIN VERBOSE.
Similar to other fields in pg_stat_activity, only the queryid from the
top level statements are exposed, and if the backends status isn't
active then the queryid from the last executed statements is displayed.
Add a %Q placeholder to include the queryid in log_line_prefix, which
will also only expose top level statements.
For EXPLAIN VERBOSE, if a query identifier has been computed, either by
enabling compute_query_id or using a third-party module, display it.
Bump catalog version.
Discussion: https://postgr.es/m/20210407125726.tkvjdbw76hxnpwfi@nol
Author: Julien Rouhaud
Reviewed-by: Alvaro Herrera, Nitin Jadhav, Zhihong Yu
2021-04-07 20:03:56 +02:00
|
|
|
# %Q = query ID (0 if none or not computed)
|
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
|
2021-01-07 16:47:03 +01:00
|
|
|
#log_recovery_conflict_waits = off # log standby recovery conflict waits
|
|
|
|
# >= deadlock_timeout
|
2020-04-02 21:04:51 +02:00
|
|
|
#log_parameter_max_length = -1 # when logging statements, limit logged
|
|
|
|
# bind-parameter values to N bytes;
|
|
|
|
# -1 means print in full, 0 disables
|
|
|
|
#log_parameter_max_length_on_error = 0 # when logging an error, limit logged
|
|
|
|
# bind-parameter values to N bytes;
|
|
|
|
# -1 means print in full, 0 disables
|
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
|
|
|
|
2021-05-25 11:49:54 +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
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#track_activity_query_size = 1024 # (change requires restart)
|
2007-09-24 05:12:23 +02:00
|
|
|
#track_counts = on
|
2012-04-29 22:23:54 +02:00
|
|
|
#track_io_timing = off
|
Track total amounts of times spent writing and syncing WAL data to disk.
This commit adds new GUC track_wal_io_timing. When this is enabled,
the total amounts of time XLogWrite writes and issue_xlog_fsync syncs
WAL data to disk are counted in pg_stat_wal. This information would be
useful to check how much WAL write and sync affect the performance.
Enabling track_wal_io_timing will make the server query the operating
system for the current time every time WAL is written or synced,
which may cause significant overhead on some platforms. To avoid such
additional overhead in the server with track_io_timing enabled,
this commit introduces track_wal_io_timing as a separate parameter from
track_io_timing.
Note that WAL write and sync activity by walreceiver has not been tracked yet.
This commit makes the server also track the numbers of times XLogWrite
writes and issue_xlog_fsync syncs WAL data to disk, in pg_stat_wal,
regardless of the setting of track_wal_io_timing. This counters can be
used to calculate the WAL write and sync time per request, for example.
Bump PGSTAT_FILE_FORMAT_ID.
Bump catalog version.
Author: Masahiro Ikeda
Reviewed-By: Japin Li, Hayato Kuroda, Masahiko Sawada, David Johnston, Fujii Masao
Discussion: https://postgr.es/m/0509ad67b585a5b86a83d445dfa75392@oss.nttdata.com
2021-03-09 08:52:06 +01:00
|
|
|
#track_wal_io_timing = off
|
2008-05-15 02:17:41 +02:00
|
|
|
#track_functions = none # none, pl, all
|
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
|
|
|
|
2021-05-15 20:13:09 +02:00
|
|
|
#compute_query_id = auto
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#log_statement_stats = off
|
2006-06-19 03:51:22 +02:00
|
|
|
#log_parser_stats = off
|
|
|
|
#log_planner_stats = off
|
|
|
|
#log_executor_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.
|
|
|
|
#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
|
Trigger autovacuum based on number of INSERTs
Traditionally autovacuum has only ever invoked a worker based on the
estimated number of dead tuples in a table and for anti-wraparound
purposes. For the latter, with certain classes of tables such as
insert-only tables, anti-wraparound vacuums could be the first vacuum that
the table ever receives. This could often lead to autovacuum workers being
busy for extended periods of time due to having to potentially freeze
every page in the table. This could be particularly bad for very large
tables. New clusters, or recently pg_restored clusters could suffer even
more as many large tables may have the same relfrozenxid, which could
result in large numbers of tables requiring an anti-wraparound vacuum all
at once.
Here we aim to reduce the work required by anti-wraparound and aggressive
vacuums in general, by triggering autovacuum when the table has received
enough INSERTs. This is controlled by adding two new GUCs and reloptions;
autovacuum_vacuum_insert_threshold and
autovacuum_vacuum_insert_scale_factor. These work exactly the same as the
existing scale factor and threshold controls, only base themselves off the
number of inserts since the last vacuum, rather than the number of dead
tuples. New controls were added rather than reusing the existing
controls, to allow these new vacuums to be tuned independently and perhaps
even completely disabled altogether, which can be done by setting
autovacuum_vacuum_insert_threshold to -1.
We make no attempt to skip index cleanup operations on these vacuums as
they may trigger for an insert-mostly table which continually doesn't have
enough dead tuples to trigger an autovacuum for the purpose of removing
those dead tuples. If we were to skip cleaning the indexes in this case,
then it is possible for the index(es) to become bloated over time.
There are additional benefits to triggering autovacuums based on inserts,
as tables which never contain enough dead tuples to trigger an autovacuum
are now more likely to receive a vacuum, which can mark more of the table
as "allvisible" and encourage the query planner to make use of Index Only
Scans.
Currently, we still obey vacuum_freeze_min_age when triggering these new
autovacuums based on INSERTs. For large insert-only tables, it may be
beneficial to lower the table's autovacuum_freeze_min_age so that tuples
are eligible to be frozen sooner. Here we've opted not to zero that for
these types of vacuums, since the table may just be insert-mostly and we
may otherwise freeze tuples that are still destined to be updated or
removed in the near future.
There was some debate to what exactly the new scale factor and threshold
should default to. For now, these are set to 0.2 and 1000, respectively.
There may be some motivation to adjust these before the release.
Author: Laurenz Albe, Darafei Praliaskouski
Reviewed-by: Alvaro Herrera, Masahiko Sawada, Chris Travers, Andres Freund, Justin Pryzby
Discussion: https://postgr.es/m/CAC8Q8t%2Bj36G_bLF%3D%2B0iMo6jGNWnLnWb1tujXuJr-%2Bx8ZCCTqoQ%40mail.gmail.com
2020-03-28 07:20:12 +01:00
|
|
|
#autovacuum_vacuum_insert_threshold = 1000 # min number of row inserts
|
2020-06-07 14:35:12 +02:00
|
|
|
# before vacuum; -1 disables insert
|
Trigger autovacuum based on number of INSERTs
Traditionally autovacuum has only ever invoked a worker based on the
estimated number of dead tuples in a table and for anti-wraparound
purposes. For the latter, with certain classes of tables such as
insert-only tables, anti-wraparound vacuums could be the first vacuum that
the table ever receives. This could often lead to autovacuum workers being
busy for extended periods of time due to having to potentially freeze
every page in the table. This could be particularly bad for very large
tables. New clusters, or recently pg_restored clusters could suffer even
more as many large tables may have the same relfrozenxid, which could
result in large numbers of tables requiring an anti-wraparound vacuum all
at once.
Here we aim to reduce the work required by anti-wraparound and aggressive
vacuums in general, by triggering autovacuum when the table has received
enough INSERTs. This is controlled by adding two new GUCs and reloptions;
autovacuum_vacuum_insert_threshold and
autovacuum_vacuum_insert_scale_factor. These work exactly the same as the
existing scale factor and threshold controls, only base themselves off the
number of inserts since the last vacuum, rather than the number of dead
tuples. New controls were added rather than reusing the existing
controls, to allow these new vacuums to be tuned independently and perhaps
even completely disabled altogether, which can be done by setting
autovacuum_vacuum_insert_threshold to -1.
We make no attempt to skip index cleanup operations on these vacuums as
they may trigger for an insert-mostly table which continually doesn't have
enough dead tuples to trigger an autovacuum for the purpose of removing
those dead tuples. If we were to skip cleaning the indexes in this case,
then it is possible for the index(es) to become bloated over time.
There are additional benefits to triggering autovacuums based on inserts,
as tables which never contain enough dead tuples to trigger an autovacuum
are now more likely to receive a vacuum, which can mark more of the table
as "allvisible" and encourage the query planner to make use of Index Only
Scans.
Currently, we still obey vacuum_freeze_min_age when triggering these new
autovacuums based on INSERTs. For large insert-only tables, it may be
beneficial to lower the table's autovacuum_freeze_min_age so that tuples
are eligible to be frozen sooner. Here we've opted not to zero that for
these types of vacuums, since the table may just be insert-mostly and we
may otherwise freeze tuples that are still destined to be updated or
removed in the near future.
There was some debate to what exactly the new scale factor and threshold
should default to. For now, these are set to 0.2 and 1000, respectively.
There may be some motivation to adjust these before the release.
Author: Laurenz Albe, Darafei Praliaskouski
Reviewed-by: Alvaro Herrera, Masahiko Sawada, Chris Travers, Andres Freund, Justin Pryzby
Discussion: https://postgr.es/m/CAC8Q8t%2Bj36G_bLF%3D%2B0iMo6jGNWnLnWb1tujXuJr-%2Bx8ZCCTqoQ%40mail.gmail.com
2020-03-28 07:20:12 +01:00
|
|
|
# vacuums
|
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
|
Trigger autovacuum based on number of INSERTs
Traditionally autovacuum has only ever invoked a worker based on the
estimated number of dead tuples in a table and for anti-wraparound
purposes. For the latter, with certain classes of tables such as
insert-only tables, anti-wraparound vacuums could be the first vacuum that
the table ever receives. This could often lead to autovacuum workers being
busy for extended periods of time due to having to potentially freeze
every page in the table. This could be particularly bad for very large
tables. New clusters, or recently pg_restored clusters could suffer even
more as many large tables may have the same relfrozenxid, which could
result in large numbers of tables requiring an anti-wraparound vacuum all
at once.
Here we aim to reduce the work required by anti-wraparound and aggressive
vacuums in general, by triggering autovacuum when the table has received
enough INSERTs. This is controlled by adding two new GUCs and reloptions;
autovacuum_vacuum_insert_threshold and
autovacuum_vacuum_insert_scale_factor. These work exactly the same as the
existing scale factor and threshold controls, only base themselves off the
number of inserts since the last vacuum, rather than the number of dead
tuples. New controls were added rather than reusing the existing
controls, to allow these new vacuums to be tuned independently and perhaps
even completely disabled altogether, which can be done by setting
autovacuum_vacuum_insert_threshold to -1.
We make no attempt to skip index cleanup operations on these vacuums as
they may trigger for an insert-mostly table which continually doesn't have
enough dead tuples to trigger an autovacuum for the purpose of removing
those dead tuples. If we were to skip cleaning the indexes in this case,
then it is possible for the index(es) to become bloated over time.
There are additional benefits to triggering autovacuums based on inserts,
as tables which never contain enough dead tuples to trigger an autovacuum
are now more likely to receive a vacuum, which can mark more of the table
as "allvisible" and encourage the query planner to make use of Index Only
Scans.
Currently, we still obey vacuum_freeze_min_age when triggering these new
autovacuums based on INSERTs. For large insert-only tables, it may be
beneficial to lower the table's autovacuum_freeze_min_age so that tuples
are eligible to be frozen sooner. Here we've opted not to zero that for
these types of vacuums, since the table may just be insert-mostly and we
may otherwise freeze tuples that are still destined to be updated or
removed in the near future.
There was some debate to what exactly the new scale factor and threshold
should default to. For now, these are set to 0.2 and 1000, respectively.
There may be some motivation to adjust these before the release.
Author: Laurenz Albe, Darafei Praliaskouski
Reviewed-by: Alvaro Herrera, Masahiko Sawada, Chris Travers, Andres Freund, Justin Pryzby
Discussion: https://postgr.es/m/CAC8Q8t%2Bj36G_bLF%3D%2B0iMo6jGNWnLnWb1tujXuJr-%2Bx8ZCCTqoQ%40mail.gmail.com
2020-03-28 07:20:12 +01:00
|
|
|
#autovacuum_vacuum_insert_scale_factor = 0.2 # fraction of inserts over table
|
|
|
|
# size before insert vacuum
|
2007-12-07 17:44:56 +01:00
|
|
|
#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
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#default_table_access_method = 'heap'
|
2007-12-07 17:44:56 +01:00
|
|
|
#default_tablespace = '' # a tablespace name, '' uses the default
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#default_toast_compression = 'pglz' # 'pglz' or 'lz4'
|
2007-12-07 17:44:56 +01:00
|
|
|
#temp_tablespaces = '' # a list of tablespace names, '' uses
|
|
|
|
# only default tablespace
|
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
|
2021-01-07 00:28:42 +01:00
|
|
|
#idle_session_timeout = 0 # in milliseconds, 0 is disabled
|
2009-01-16 14:27:24 +01:00
|
|
|
#vacuum_freeze_table_age = 150000000
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#vacuum_freeze_min_age = 50000000
|
Add wraparound failsafe to VACUUM.
Add a failsafe mechanism that is triggered by VACUUM when it notices
that the table's relfrozenxid and/or relminmxid are dangerously far in
the past. VACUUM checks the age of the table dynamically, at regular
intervals.
When the failsafe triggers, VACUUM takes extraordinary measures to
finish as quickly as possible so that relfrozenxid and/or relminmxid can
be advanced. VACUUM will stop applying any cost-based delay that may be
in effect. VACUUM will also bypass any further index vacuuming and heap
vacuuming -- it only completes whatever remaining pruning and freezing
is required. Bypassing index/heap vacuuming is enabled by commit
8523492d, which made it possible to dynamically trigger the mechanism
already used within VACUUM when it is run with INDEX_CLEANUP off.
It is expected that the failsafe will almost always trigger within an
autovacuum to prevent wraparound, long after the autovacuum began.
However, the failsafe mechanism can trigger in any VACUUM operation.
Even in a non-aggressive VACUUM, where we're likely to not advance
relfrozenxid, it still seems like a good idea to finish off remaining
pruning and freezing. An aggressive/anti-wraparound VACUUM will be
launched immediately afterwards. Note that the anti-wraparound VACUUM
that follows will itself trigger the failsafe, usually before it even
begins its first (and only) pass over the heap.
The failsafe is controlled by two new GUCs: vacuum_failsafe_age, and
vacuum_multixact_failsafe_age. There are no equivalent reloptions,
since that isn't expected to be useful. The GUCs have rather high
defaults (both default to 1.6 billion), and are expected to generally
only be used to make the failsafe trigger sooner/more frequently.
Author: Masahiko Sawada <sawada.mshk@gmail.com>
Author: Peter Geoghegan <pg@bowt.ie>
Discussion: https://postgr.es/m/CAD21AoD0SkE11fMw4jD4RENAwBMcw1wasVnwpJVw3tVqPOQgAw@mail.gmail.com
Discussion: https://postgr.es/m/CAH2-WzmgH3ySGYeC-m-eOBsa2=sDwa292-CFghV4rESYo39FsQ@mail.gmail.com
2021-04-07 21:37:45 +02:00
|
|
|
#vacuum_failsafe_age = 1600000000
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#vacuum_multixact_freeze_table_age = 150000000
|
|
|
|
#vacuum_multixact_freeze_min_age = 5000000
|
Add wraparound failsafe to VACUUM.
Add a failsafe mechanism that is triggered by VACUUM when it notices
that the table's relfrozenxid and/or relminmxid are dangerously far in
the past. VACUUM checks the age of the table dynamically, at regular
intervals.
When the failsafe triggers, VACUUM takes extraordinary measures to
finish as quickly as possible so that relfrozenxid and/or relminmxid can
be advanced. VACUUM will stop applying any cost-based delay that may be
in effect. VACUUM will also bypass any further index vacuuming and heap
vacuuming -- it only completes whatever remaining pruning and freezing
is required. Bypassing index/heap vacuuming is enabled by commit
8523492d, which made it possible to dynamically trigger the mechanism
already used within VACUUM when it is run with INDEX_CLEANUP off.
It is expected that the failsafe will almost always trigger within an
autovacuum to prevent wraparound, long after the autovacuum began.
However, the failsafe mechanism can trigger in any VACUUM operation.
Even in a non-aggressive VACUUM, where we're likely to not advance
relfrozenxid, it still seems like a good idea to finish off remaining
pruning and freezing. An aggressive/anti-wraparound VACUUM will be
launched immediately afterwards. Note that the anti-wraparound VACUUM
that follows will itself trigger the failsafe, usually before it even
begins its first (and only) pass over the heap.
The failsafe is controlled by two new GUCs: vacuum_failsafe_age, and
vacuum_multixact_failsafe_age. There are no equivalent reloptions,
since that isn't expected to be useful. The GUCs have rather high
defaults (both default to 1.6 billion), and are expected to generally
only be used to make the failsafe trigger sooner/more frequently.
Author: Masahiko Sawada <sawada.mshk@gmail.com>
Author: Peter Geoghegan <pg@bowt.ie>
Discussion: https://postgr.es/m/CAD21AoD0SkE11fMw4jD4RENAwBMcw1wasVnwpJVw3tVqPOQgAw@mail.gmail.com
Discussion: https://postgr.es/m/CAH2-WzmgH3ySGYeC-m-eOBsa2=sDwa292-CFghV4rESYo39FsQ@mail.gmail.com
2021-04-07 21:37:45 +02:00
|
|
|
#vacuum_multixact_failsafe_age = 1600000000
|
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'
|
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
|
|
|
|
2006-08-15 20:26:59 +02:00
|
|
|
#local_preload_libraries = ''
|
2013-11-26 06:00:37 +01:00
|
|
|
#session_preload_libraries = ''
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#shared_preload_libraries = '' # (change requires restart)
|
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'
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#gin_fuzzy_search_limit = 0
|
2003-07-18 21:16:03 +02:00
|
|
|
|
2021-05-25 11:49:54 +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
|
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)
|
Sync guc.c and postgresql.conf.sample with the SGML docs.
It seems that various people have moved GUCs around in the config.sgml
listing without bothering to make the code agree. Ensure that the
config_group codes assigned to GUCs match where they are listed in
config.sgml. Likewise ensure that postgresql.conf.sample lists GUCs
in the same sub-section and same ordering as they appear in config.sgml.
(I've got some doubts about some of these choices, but for the purposes
of this patch, we'll treat config.sgml as gospel.)
Notably, this requires adding a WAL_RECOVERY config_group value,
because 1d257577e didn't. As long as we're renumbering that enum
anyway, let's take out the values corresponding to major groups
that are divided into sub-groups. No GUC should be assigned to the
major group itself, so those values just create a temptation to
do the wrong thing, while adding work for translators.
In passing, adjust the short_desc strings for PRESET_OPTIONS GUCs
to uniformly use the phrasing "Shows XYZ.", removing the impression
some of these strings left that you can set the value.
While some of these errors are old, no back-patch, as changing the
contents of the pg_settings view in stable branches seems more likely
to be seen as a compatibility break than anything helpful.
Bharath Rupireddy, Justin Pryzby, Tom Lane
Discussion: https://postgr.es/m/16997-ff16127f6e0d1390@postgresql.org
Discussion: https://postgr.es/m/20210413123139.GE6091@telsasoft.com
2021-05-08 18:13:33 +02:00
|
|
|
#recovery_init_sync_method = fsync # fsync, syncfs (Linux 5.8+)
|
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
|