- linkend="sql-prepare-transaction">).
+ linkend="sql-prepare-transaction"/ >).
Setting this parameter to zero (which is the default)
disables the prepared-transaction feature.
This parameter can only be set at server start.
should be set to zero to prevent accidental creation of prepared
transactions. If you are using prepared transactions, you will
probably want max_prepared_transactions to be at
- least as large as , so that every
+ least as large as />, so that every
session can have a prepared transaction pending.
Note that when autovacuum runs, up to
- times this memory
+ /> times this memory
may be allocated, so be careful not to set the default value
too high. It may be useful to control for this by separately
- setting .
+ setting />.
Specifies the maximum amount of memory to be used by each
autovacuum worker process. It defaults to -1, indicating that
- the value of should
+ the value of /> should
be used instead. The setting has no effect on the behavior of
VACUUM when run in other contexts.
Cost-based Vacuum Delay
- During the execution of
- and
+ During the execution of />
+ and />
commands, the system maintains an
internal counter that keeps track of the estimated cost of the
various I/O operations that are performed. When the accumulated
the OS writes data back in larger batches in the background. Often
that will result in greatly reduced transaction latency, but there
also are some cases, especially with workloads that are bigger than
- , but smaller than the OS's page
+ />, but smaller than the OS's page
cache, where performance might degrade. This setting may have no
effect on some platforms. The valid range is between
0 , which disables forced writeback, and
The default is 1 on supported systems, otherwise 0. This value can
be overridden for tables in a particular tablespace by setting the
tablespace parameter of the same name (see
- ).
+ />).
When changing this value, consider also adjusting
- and
- .
+ /> and
+ />.
Sets the maximum number of workers that can be started by a single
Gather or Gather Merge node.
Parallel workers are taken from the pool of processes established by
- , limited by
- . Note that the requested
+ />, limited by
+ />. Note that the requested
number of workers may not actually be available at run time. If this
occurs, the plan will run with fewer workers than expected, which may
be inefficient. The default value is 2. Setting this value to 0
system as an additional user session. This should be taken into
account when choosing a value for this setting, as well as when
configuring other settings that control resource utilization, such
- as . Resource limits such as
+ as />. Resource limits such as
work_mem are applied individually to each worker,
which means the total utilization may be much higher across all
processes than it would normally be for any single process.
For more information on parallel query, see
- .
+ />.
Sets the maximum number of workers that the system can support for
parallel queries. The default value is 8. When increasing or
decreasing this value, consider also adjusting
- .
+ />.
Also, note that a setting for this value which is higher than
- will have no effect,
+ /> will have no effect,
since parallel workers are taken from the pool of worker processes
established by that setting.
checkpoint, or when the OS writes data back in larger batches in the
background. Often that will result in greatly reduced transaction
latency, but there also are some cases, especially with workloads
- that are bigger than , but smaller
+ that are bigger than />, but smaller
than the OS's page cache, where performance might degrade. This
setting may have no effect on some platforms. The valid range is
between 0 , which disables forced writeback,
For additional information on tuning these settings,
- see .
+ see />.
In minimal level, WAL-logging of some bulk
operations can be safely skipped, which can make those
- operations much faster (see ).
+ operations much faster (see />).
Operations in which this optimization can be applied include:
CREATE TABLE AS
But minimal WAL does not contain enough information to reconstruct the
data from a base backup and the WAL logs, so replica or
higher must be used to enable WAL archiving
- () and streaming replication.
+ (/>) and streaming replication.
In logical level, the same information is logged as
If this parameter is on, the
PostgreSQL server
will try to make sure that updates are physically written to
disk, by issuing fsync() system calls or various
- equivalent methods (see ).
+ equivalent methods (see />).
This ensures that the database cluster can recover to a
consistent state after an operating system or hardware crash.
- In many situations, turning off
+ In many situations, turning off />
for noncritical transactions can provide much of the potential
performance benefit of turning off fsync , without
the attendant risks of data corruption.
fsync can only be set in the postgresql.conf
file or on the server command line.
If you turn this parameter off, also consider turning off
- .
+ />.
is on . When off , there can be a delay between
when success is reported to the client and when the transaction is
really guaranteed to be safe against a server crash. (The maximum
- delay is three times .) Unlike
- , setting this parameter to off
+ delay is three times />.) Unlike
+ />, setting this parameter to off
does not create any risk of database inconsistency: an operating
system or database crash might
result in some recent allegedly-committed transactions being lost, but
been aborted cleanly. So, turning synchronous_commit off
can be a useful alternative when performance is more important than
exact certainty about the durability of a transaction. For more
- discussion see .
+ discussion see />.
- If is non-empty, this
+ If /> is non-empty, this
parameter also controls whether or not transaction commits will wait
for their WAL records to be replicated to the standby server(s).
When set to on , commits will wait until replies
necessary to change this setting or other aspects of your system
configuration in order to create a crash-safe configuration or
achieve optimal performance.
- These aspects are discussed in .
+ These aspects are discussed in />.
This parameter can only be set in the postgresql.conf
file or on the server command line.
Turning off this parameter does not affect use of
WAL archiving for point-in-time recovery (PITR)
- (see ).
+ (see />).
When this parameter is
on , the
PostgreSQL server compresses a full page image written to WAL when
- is on or during a base backup.
+ /> is on or during a base backup.
A compressed page image will be decompressed during WAL replay.
The default value is off .
Only superusers can change this setting.
The amount of shared memory used for WAL data that has not yet been
written to disk. The default setting of -1 selects a size equal to
- 1/32nd (about 3%) of , but not less
+ 1/32nd (about 3%) of />, but not less
than 64kB nor more than the size of one WAL
segment, typically 16MB . This value can be set
manually if the automatic choice is too large or too small,
checkpoint, or when the OS writes data back in larger batches in the
background. Often that will result in greatly reduced transaction
latency, but there also are some cases, especially with workloads
- that are bigger than , but smaller
+ that are bigger than />, but smaller
than the OS's page cache, where performance might degrade. This
setting may have no effect on some platforms. The valid range is
between 0 , which disables forced writeback,
When archive_mode is enabled, completed WAL segments
are sent to archive storage by setting
- . In addition to off ,
+ />. In addition to off ,
to disable, there are two modes: on , and
always . During normal operation, there is no
difference between the two modes, but when set to always
the WAL archiver is enabled also during archive recovery or standby
mode. In always mode, all files restored from the archive
or streamed with streaming replication will be archived (again). See
- for details.
+ /> for details.
archive_mode and archive_command are
Use %% to embed an actual % character in the
command. It is important for the command to return a zero
exit status only if it succeeds. For more information see
- .
+ />.
This parameter can only be set in the postgresql.conf
- The is only invoked for
+ The /> is only invoked for
completed WAL segments. Hence, if your server generates little WAL
traffic (or has slack periods where it does so), there could be a
long delay between the completion of a transaction and its safe
These settings control the behavior of the built-in
streaming replication feature (see
- ). Servers will be either a
+ />). Servers will be either a
Master or a Standby server. Masters can send data, while Standby(s)
are always receivers of replicated data. When cascading replication
- (see ) is used, Standby server(s)
+ (see />) is used, Standby server(s)
can also be senders, as well as receivers.
Parameters are mainly for Sending and Standby servers, though some
parameters have meaning only on the Master server. Settings may vary
processes). The default is 10. The value 0 means replication is
disabled. WAL sender processes count towards the total number
of connections, so the parameter cannot be set higher than
- . Abrupt streaming client
+ />. Abrupt streaming client
disconnection might cause an orphaned connection slot until
a timeout is reached, so this parameter should be set slightly
higher than the maximum number of expected clients so disconnected
Specifies the maximum number of replication slots
- (see ) that the server
+ (see />) that the server
can support. The default is 10. This parameter can only be set at
server start.
wal_level must be set
These parameters can be set on the master/primary server that is
to send replication data to one or more standby servers.
Note that in addition to these parameters,
- must be set appropriately on the master
+ /> must be set appropriately on the master
server, and optionally WAL archiving can be enabled as
- well (see ).
+ well (see />).
The values of these parameters on standby servers are irrelevant,
although you may wish to set them there in preparation for the
possibility of a standby becoming the master.
Specifies a list of standby servers that can support
synchronous replication , as described in
- .
+ />.
There will be one or more active synchronous standbys;
transactions waiting for commit will be allowed to proceed after
these standby servers confirm receipt of their data.
replication. This is the default configuration. Even when
synchronous replication is enabled, individual transactions can be
configured not to wait for replication by setting the
- parameter to
+ /> parameter to
local or off .
removed as soon as possible, that is, as soon as they are no longer
visible to any open transaction. You may wish to set this to a
non-zero value on a primary server that is supporting hot standby
- servers, as described in . This allows
+ servers, as described in />. This allows
more time for queries on the standby to complete without incurring
conflicts due to early cleanup of rows. However, since the value
is measured in terms of number of write transactions occurring on the
Specifies whether or not you can connect and run queries during
- recovery, as described in .
+ recovery, as described in />.
The default value is on .
This parameter can only be set at server start. It only has effect
during archive recovery or in standby mode.
When Hot Standby is active, this parameter determines how long the
standby server should wait before canceling standby queries that
conflict with about-to-be-applied WAL entries, as described in
- .
+ />.
max_standby_archive_delay applies when WAL data is
being read from WAL archive (and is therefore not current).
The default is 30 seconds. Units are milliseconds if not specified.
When Hot Standby is active, this parameter determines how long the
standby server should wait before canceling standby queries that
conflict with about-to-be-applied WAL entries, as described in
- .
+ />.
max_standby_streaming_delay applies when WAL data is
being received via streaming replication.
The default is 30 seconds. Units are milliseconds if not specified.
choose a different plan.
Better ways to improve the quality of the
plans chosen by the optimizer include adjusting the planner cost
- constants (see ),
- running manually, increasing
+ constants (see />),
+ running /> manually, increasing
the value of the
- linkend="guc-default-statistics-target"> configuration parameter,
+ linkend="guc-default-statistics-target"/ > configuration parameter,
and increasing the amount of statistics collected for
specific columns using ALTER TABLE SET
STATISTICS.
Enables or disables the query planner's use of index-only-scan plan
- types (see ).
+ types (see />).
The default is on .
that is part of a series of sequential fetches. The default is 1.0.
This value can be overridden for tables and indexes in a particular
tablespace by setting the tablespace parameter of the same name
- (see ).
+ (see />).
non-sequentially-fetched disk page. The default is 4.0.
This value can be overridden for tables and indexes in a particular
tablespace by setting the tablespace parameter of the same name
- (see ).
+ (see />).
complex queries (those joining many relations), at the cost of producing
plans that are sometimes inferior to those found by the normal
exhaustive-search algorithm.
- For more information see .
+ For more information see />.
do ANALYZE , but might improve the quality of the
planner's estimates. The default is 100. For more information
on the use of statistics by the
PostgreSQL - query planner, refer to .
+ query planner, refer to />.
- Refer to for
+ Refer to /> for
more information on using constraint exclusion and partitioning.
resulting FROM list would have no more than
this many items. Smaller values reduce planning time but might
yield inferior query plans. The default is eight.
- For more information see .
+ For more information see />.
- Setting this value to or more
+ Setting this value to /> or more
may trigger use of the GEQO planner, resulting in non-optimal
- plans. See .
+ plans. See />.
the optimal join order, advanced users can elect to
temporarily set this variable to 1, and then specify the join
order they desire explicitly.
- For more information see .
+ For more information see />.
- Setting this value to or more
+ Setting this value to /> or more
may trigger use of the GEQO planner, resulting in non-optimal
- plans. See .
+ plans. See />.
log entries are output in comma separated
value (
CSV ) format, which is convenient for
loading logs into programs.
- See for details.
- must be enabled to generate
+ See /> for details.
+ /> must be enabled to generate
CSV-format log output.
log_destination .
PostgreSQL
can log to
syslog facilities
LOCAL0 through
LOCAL7 (see
- linkend="guc-syslog-facility">), but the default
+ linkend="guc-syslog-facility"/ >), but the default
syslog configuration on most platforms
will discard all such messages. You will need to add something like:
register an event source and its library with the operating
system so that the Windows Event Viewer can display event
log messages cleanly.
- See for details.
+ See /> for details.
file names. (Note that if there are
any time-zone-dependent % -escapes, the computation
is done in the zone specified
- by .)
+ by />.)
The supported % -escapes are similar to those
listed in the Open Group's
url="http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html">strftime
server owner can read or write the log files. The other commonly
useful setting is 0640 , allowing members of the owner's
group to read the files. Note however that to make use of such a
- setting, you'll need to alter to
+ setting, you'll need to alter /> to
store the files somewhere outside the cluster data directory. In
any case, it's unwise to make the log files world-readable, since
they might contain sensitive data.
When using this option together with
- ,
+ />,
the text of statements that are logged because of
log_statement will not be repeated in the
duration log message.
If you are not using
syslog , it is recommended
that you log the PID or session ID using
-
+ />
so that you can link the statement message to the later
duration message using the process ID or session ID.
- explains the message
+ /> explains the message
severity levels used by
PostgreSQL . If logging output
is sent to syslog or Windows'
eventlog , the severity levels are translated
It is typically set by an application upon connection to the server.
The name will be displayed in the pg_stat_activity view
and included in CSV log entries. It can also be included in regular
- log entries via the parameter.
+ log entries via the /> parameter.
Only printable ASCII characters may be used in the
application_name value. Other characters will be
replaced with question marks (? ).
These messages are emitted at LOG message level, so by
default they will appear in the server log but will not be sent to the
client. You can change that by adjusting
- and/or
- .
+ /> and/or
+ />.
These parameters are off by default.
The difference between setting this option and setting
- to zero is that
+ /> to zero is that
exceeding log_min_duration_statement forces the text of
the query to be logged, but this option doesn't. Thus, if
log_duration is on and
the logging of DETAIL , HINT ,
QUERY , and CONTEXT error information.
VERBOSE output includes the SQLSTATE error
- code (see also ) and the source code file name, function name,
+ code (see also />) and the source code file name, function name,
and line number that generated the error.
Only superusers can change this setting.
Controls whether a log message is produced when a session waits
- longer than to acquire a
+ longer than /> to acquire a
lock. This is useful in determining if lock waits are causing
poor performance. The default is off .
Only superusers can change this setting.
Causes each replication command to be logged in the server log.
- See for more information about
+ See /> for more information about
replication command. The default value is off .
Only superusers can change this setting.
Sets the time zone used for timestamps written in the server log.
- Unlike , this value is cluster-wide,
+ Unlike />, this value is cluster-wide,
so that all sessions will report timestamps consistently.
The built-in default is GMT , but that is typically
overridden in
postgresql.conf ;
initdb will install a setting there corresponding to its system environment.
- See for more information.
+ See /> for more information.
This parameter can only be set in the postgresql.conf
file or on the server command line.
These settings control how process titles of server processes are
modified. Process titles are typically viewed using programs like
ps or, on Windows,
Process Explorer .
- See for details.
+ See /> for details.
When statistics collection is enabled, the data that is produced can be
accessed via the pg_stat and
pg_statio family of system views.
- Refer to for more information.
+ Refer to /> for more information.
Enables timing of database I/O calls. This parameter is off by
default, because it will repeatedly query the operating system for
the current time, which may cause significant overhead on some
- platforms. You can use the tool to
+ platforms. You can use the /> tool to
measure the overhead of timing on your system.
I/O timing information is
- displayed in , in the output of
- when the BUFFERS option is
- used, and by . Only superusers can
+ displayed in />, in the output of
+ /> when the BUFFERS option is
+ used, and by />. Only superusers can
change this setting.
These settings control the behavior of the autovacuum
- feature. Refer to for more information.
+ feature. Refer to /> for more information.
Note that many of these settings can be overridden on a per-table
basis; see
- endterm="sql-createtable-storage-parameters-title">.
+ endterm="sql-createtable-storage-parameters-title"/ >.
Controls whether the server should run the
autovacuum launcher daemon. This is on by default; however,
- must also be enabled for
+ /> must also be enabled for
autovacuum to work.
This parameter can only be set in the postgresql.conf
file or on the server command line; however, autovacuuming can be
Note that even when this parameter is disabled, the system
will launch autovacuum processes if necessary to
prevent transaction ID wraparound. See
- linkend="vacuum-for-wraparound"> for more information.
+ linkend="vacuum-for-wraparound"/ > for more information.
This parameter can only be set at server start, but the setting
can be reduced for individual tables by
changing table storage parameters.
- For more information see .
+ For more information see />.
400 million multixacts.
This parameter can only be set at server start, but the setting can
be reduced for individual tables by changing table storage parameters.
- For more information see .
+ For more information see />.
Specifies the cost delay value that will be used in automatic
VACUUM operations. If -1 is specified, the regular
- value will be used.
+ /> value will be used.
The default value is 20 milliseconds.
This parameter can only be set in the postgresql.conf
file or on the server command line;
Specifies the cost limit value that will be used in automatic
VACUUM operations. If -1 is specified (which is the
default), the regular
- value will be used. Note that
+ /> value will be used. Note that
the value is distributed proportionally among the running autovacuum
workers, if there is more than one, so that the sum of the limits for
each worker does not exceed the value of this variable.
The current effective value of the search path can be examined
current_schemas
- (see ).
+ (see />).
This is not quite the same as
examining the value of search_path , since
current_schemas shows how the items
- For more information on schema handling, see .
+ For more information on schema handling, see />.
For more information on row security policies,
- see .
+ see />.
This variable is not used for temporary tables; for them,
- is consulted instead.
+ /> is consulted instead.
For more information on tablespaces,
- see .
+ see />.
- See also .
+ See also />.
This parameter is normally on. When set to off , it
disables validation of the function body string during
- linkend="sql-createfunction">. Disabling validation avoids side
+ linkend="sql-createfunction"/ >. Disabling validation avoids side
effects of the validation process and avoids false positives due
to problems such as forward references. Set this parameter
to off before loading functions on behalf of other
- Consult
and
- linkend="sql-set-transaction"> for more information.
+ Consult
/> and
+ linkend="sql-set-transaction"/ > for more information.
- Consult for more information.
+ Consult /> for more information.
- Consult for more information.
+ Consult /> for more information.
superuser privilege and results in discarding any previously cached
query plans. Possible values are origin (the default),
replica and local .
- See for
+ See /> for
more information.
longer than the specified duration in milliseconds. This allows any
locks held by that session to be released and the connection slot to be reused;
it also allows tuples visible only to this transaction to be vacuumed. See
- for more details about this.
+ /> for more details about this.
The default value of 0 disables this feature.
tuples. The default is 150 million transactions. Although users can
set this value anywhere from zero to two billions, VACUUM
will silently limit the effective value to 95% of
- , so that a
+ />, so that a
periodical manual VACUUM has a chance to run before an
anti-wraparound autovacuum is launched for the table. For more
information see
- .
+ />.
The default is 50 million transactions. Although
users can set this value anywhere from zero to one billion,
VACUUM will silently limit the effective value to half
- the value of , so
+ the value of />, so
that there is not an unreasonably short time between forced
autovacuums. For more information see
- linkend="vacuum-for-wraparound">.
+ linkend="vacuum-for-wraparound"/ >.
tuples. The default is 150 million multixacts.
Although users can set this value anywhere from zero to two billions,
VACUUM will silently limit the effective value to 95% of
- , so that a
+ />, so that a
periodical manual VACUUM has a chance to run before an
anti-wraparound is launched for the table.
- For more information see .
+ For more information see />.
is 5 million multixacts.
Although users can set this value anywhere from zero to one billion,
VACUUM will silently limit the effective value to half
- the value of ,
+ the value of />,
so that there is not an unreasonably short time between forced
autovacuums.
- For more information see .
+ For more information see />.
Sets the output format for values of type bytea .
Valid values are hex (the default)
and escape (the traditional PostgreSQL
- format). See for more
+ format). See /> for more
information. The bytea type always
accepts both formats on input, regardless of this setting.
base64 and hex , which
are both defined in the XML Schema standard. The default is
base64 . For further information about
- XML-related functions, see .
+ XML-related functions, see />.
Sets whether DOCUMENT or
CONTENT is implicit when converting between
XML and character string values. See
- linkend="datatype-xml"> for a description of this. Valid
+ linkend="datatype-xml"/ > for a description of this. Valid
values are DOCUMENT and
CONTENT . The default is
CONTENT .
The default is four megabytes (4MB ). This setting
can be overridden for individual GIN indexes by changing
index storage parameters.
- See > and >
+ See /> and >
for more information.
and European are synonyms for DMY ; the
keywords US , NonEuro , and
NonEuropean are synonyms for MDY . See
- for more information. The
+ /> for more information. The
built-in default is ISO, MDY , but
initdb will initialize the
configuration file with a setting that corresponds to the
output matching
SQL standard interval literals.
The value postgres (which is the default) will produce
output matching
PostgreSQL releases prior to 8.4
- when the
+ when the />
parameter was set to ISO .
The value postgres_verbose will produce output
matching
PostgreSQL releases prior to 8.4
The IntervalStyle parameter also affects the
interpretation of ambiguous interval input. See
- for more information.
+ /> for more information.
The built-in default is GMT , but that is typically
overridden in
postgresql.conf ;
initdb will install a setting there corresponding to its system environment.
- See for more information.
+ See /> for more information.
which is a collection that works in most of the world; there are
also 'Australia' and 'India' ,
and other collections can be defined for a particular installation.
- See for more information.
+ See /> for more information.
partially-significant digits; this is especially useful for dumping
float data that needs to be restored exactly. Or it can be set
negative to suppress unwanted digits.
- See also .
+ See also />.
Sets the client-side encoding (character set).
The default is to use the database encoding.
The character sets supported by the
PostgreSQL - server are described in .
+ server are described in />.
Sets the language in which messages are displayed. Acceptable
- values are system-dependent; see for
+ values are system-dependent; see /> for
more information. If this variable is set to the empty string
(which is the default) then the value is inherited from the
execution environment of the server in a system-dependent way.
Sets the locale to use for formatting monetary amounts, for
example with the to_char family of
functions. Acceptable values are system-dependent; see
- linkend="locale"> for more information. If this variable is
+ linkend="locale"/ > for more information. If this variable is
set to the empty string (which is the default) then the value
is inherited from the execution environment of the server in a
system-dependent way.
Sets the locale to use for formatting numbers, for example
with the to_char family of
functions. Acceptable values are system-dependent; see
- linkend="locale"> for more information. If this variable is
+ linkend="locale"/ > for more information. If this variable is
set to the empty string (which is the default) then the value
is inherited from the execution environment of the server in a
system-dependent way.
Sets the locale to use for formatting dates and times, for example
with the to_char family of
functions. Acceptable values are system-dependent; see
- linkend="locale"> for more information. If this variable is
+ linkend="locale"/ > for more information. If this variable is
set to the empty string (which is the default) then the value
is inherited from the execution environment of the server in a
system-dependent way.
Selects the text search configuration that is used by those variants
of the text search functions that do not have an explicit argument
specifying the configuration.
- See for further information.
+ See /> for further information.
The built-in default is pg_catalog.simple , but
initdb will initialize the
configuration file with a setting that corresponds to the
This variable specifies one or more shared libraries that are to be
preloaded at connection start.
It contains a comma-separated list of library names, where each name
- is interpreted as for the command.
+ is interpreted as for the /> command.
Whitespace between entries is ignored; surround a library name with
double quotes if you need to include whitespace or commas in the name.
The parameter value only takes effect at the start of the connection.
However, unless a module is specifically designed to be used in this way by
non-superusers, this is usually not the right setting to use. Look
- at instead.
+ at /> instead.
This variable specifies one or more shared libraries that are to be
preloaded at connection start.
It contains a comma-separated list of library names, where each name
- is interpreted as for the command.
+ is interpreted as for the /> command.
Whitespace between entries is ignored; surround a library name with
double quotes if you need to include whitespace or commas in the name.
The parameter value only takes effect at the start of the connection.
performance-measurement libraries to be loaded into specific sessions
without an explicit
LOAD command being given. For
- example, could be enabled for all
+ example, /> could be enabled for all
sessions under a given user name by setting this parameter
with ALTER ROLE SET . Also, this parameter can be changed
without restarting the server (but changes only take effect when a new
- Unlike , there is no large
+ Unlike />, there is no large
performance advantage to loading a library at session start rather than
when it is first used. There is some advantage, however, when
connection pooling is used.
This variable specifies one or more shared libraries to be preloaded at
server start.
It contains a comma-separated list of library names, where each name
- is interpreted as for the command.
+ is interpreted as for the /> command.
Whitespace between entries is ignored; surround a library name with
double quotes if you need to include whitespace or commas in the name.
This parameter can only be set at server start. If a specified
parameter is recommended only for libraries that will be used in most
sessions. Also, changing this parameter requires a server restart, so
this is not the right setting to use for short-term debugging tasks,
- say. Use for that
+ say. Use /> for that
instead.
Soft upper limit of the size of the set returned by GIN index scans. For more
- information see .
+ information see />.
- When is set,
+ When /> is set,
this parameter also determines the length of time to wait before
a log message is issued about the lock wait. If you are trying
to investigate locking delays you might want to set a shorter than
The shared lock table tracks locks on
max_locks_per_transaction * (
- linkend="guc-max-connections"> +
- linkend="guc-max-prepared-transactions">) objects (e.g., tables);
+ linkend="guc-max-connections"
/ > +
+ linkend="guc-max-prepared-transactions"/ >) objects (e.g., tables);
hence, no more than this many distinct objects can be locked at
any one time. This parameter controls the average number of object
locks allocated for each transaction; individual transactions
The shared predicate lock table tracks locks on
max_pred_locks_per_transaction * (
- linkend="guc-max-connections"> +
- linkend="guc-max-prepared-transactions">) objects (e.g., tables);
+ linkend="guc-max-connections"
/ > +
+ linkend="guc-max-prepared-transactions"/ >) objects (e.g., tables);
hence, no more than this many distinct objects can be locked at
any one time. This parameter controls the average number of object
locks allocated for each transaction; individual transactions
predicate-locked before the lock is promoted to covering the whole
relation. Values greater than or equal to zero mean an absolute
limit, while negative values
- mean divided by
+ mean /> divided by
the absolute value of this setting. The default is -2, which keeps
the behavior from previous versions of
PostgreSQL .
This parameter can only be set in the postgresql.conf
- See for more information.
+ See /> for more information.
output of EXPLAIN as well as the results of functions
like pg_get_viewdef . See also the
--quote-all-identifiers option of
- > and >.
+ /> and >.
parameter to determine how string literals will be processed.
The presence of this parameter can also be taken as an indication
that the escape string syntax (E'...' ) is supported.
- Escape string syntax ()
+ Escape string syntax (/>)
should be used if an application desires
backslashes to be treated as escape characters.
- Refer to for related information.
+ Refer to /> for related information.
Reports the size of a disk block. It is determined by the value
of BLCKSZ when building the server. The default
value is 8192 bytes. The meaning of some configuration
- variables (such as ) is
+ variables (such as />) is
influenced by
block_size . See
- linkend="runtime-config-resource"> for information.
+ linkend="runtime-config-resource"/ > for information.
Reports whether data checksums are enabled for this cluster.
- See for more information.
+ See /> for more information.
Reports the locale in which sorting of textual data is done.
- See for more information.
+ See /> for more information.
This value is determined when a database is created.
Reports the locale that determines character classifications.
- See for more information.
+ See /> for more information.
This value is determined when a database is created.
Ordinarily this will be the same as lc_collate ,
but for special applications it might be set differently.
Reports the database encoding (character set).
It is determined when the database is created. Ordinarily,
clients need only be concerned with the value of
- linkend="guc-client-encoding">.
+ linkend="guc-client-encoding"/ >.
Reports the number of blocks (pages) in a WAL segment file.
The total size of a WAL segment file in bytes is equal to
wal_segment_size multiplied by wal_block_size ;
- by default this is 16MB. See for
+ by default this is 16MB. See /> for
more information.
Generates a great amount of debugging output for the
LISTEN and NOTIFY
- commands. or
- must be
+ commands. /> or
+ /> must be
DEBUG1 or lower to send this output to the
client or server logs, respectively.
Enables logging of recovery-related debugging output that otherwise
would not be logged. This parameter allows the user to override the
- normal setting of , but only for
+ normal setting of />, but only for
specific messages. This is intended for use in debugging Hot Standby.
Valid values are DEBUG5 , DEBUG4 ,
DEBUG3 , DEBUG2 , DEBUG1 , and
- Only has effect if are enabled.
+ Only has effect if /> are enabled.
Detection of a checksum failure during a read normally causes
For convenience there are also single letter command-line option
switches available for some parameters. They are described in
- . Some of these
+ />. Some of these
options exist for historical reasons, and their presence as a
single-letter option does not necessarily indicate an endorsement
to use the option heavily.
This appendix covers extensions and other server plug-in modules found in
- contrib . covers utility
+ contrib . /> covers utility
programs.
When building from the source distribution, these components are not built
automatically, unless you build the "world" target
- (see ).
+ (see />).
You can build and install all of them by running:
make
To make use of one of these modules, after you have installed the code
you need to register the new SQL objects in the database system.
In
PostgreSQL 9.1 and later, this is done by executing
- a command. In a fresh database,
+ a /> command. In a fresh database,
you can simply do
This will update the pre-9.1 objects of the module into a proper
extension object. Future updates to the module will be
- managed by .
+ managed by />.
For more information about extension updates, see
- .
+ />.
Note, however, that some of these modules are not extensions
in this sense, but are loaded into the server in some other way, for instance
by way of
- . See the documentation of each
+ />. See the documentation of each
module for details.
This appendix and the previous one contain information regarding the modules that
can be found in the contrib directory of the
-
PostgreSQL distribution. See
for +
PostgreSQL distribution. See
/> for more information about the contrib section in general and
server extensions and plug-ins found in contrib
specifically.
This section covers
PostgreSQL client
applications in contrib . They can be run from anywhere,
independent of where the database server resides. See
- also for information about client
+ also /> for information about client
applications that part of the core
PostgreSQL distribution.
This section covers
PostgreSQL server-related
applications in contrib . They are typically run on the
host where the database server resides. See also
- linkend="reference-server"> for information about server applications that
+ linkend="reference-server"/ > for information about server applications that
part of the core
PostgreSQL distribution.
Syntax
- shows the valid external
+ /> shows the valid external
representations for the cube
type. x , y , etc. denote
floating-point numbers.
Usage
- shows the operators provided for
+ /> shows the operators provided for
type cube .
- shows the available functions.
+ /> shows the available functions.
Convert a custom path to a finished plan. The return value will generally
be a CustomScan object, which the callback must allocate and
- initialize. See for more details.
+ initialize. See /> for more details.
PostgreSQL has a rich set of native data
types available to users. Users can add new types to
PostgreSQL using the
- linkend="sql-createtype"> command.
+ linkend="sql-createtype"/ > command.
- shows all the built-in general-purpose data
+ /> shows all the built-in general-purpose data
types. Most of the alternative names listed in the
Aliases
column are the names used internally by
PostgreSQL for historical reasons. In
Numeric types consist of two-, four-, and eight-byte integers,
four- and eight-byte floating-point numbers, and selectable-precision
- decimals. lists the
+ decimals. /> lists the
available types.
The syntax of constants for the numeric types is described in
- . The numeric types have a
+ />. The numeric types have a
full set of corresponding arithmetic operators and
- functions. Refer to for more
+ functions. Refer to /> for more
information. The following sections describe the types in detail.
The maximum allowed precision when explicitly specified in the
type declaration is 1000; NUMERIC without a specified
precision is subject to the limits described in
- linkend="datatype-numeric-table">.
+ linkend="datatype-numeric-table"/ >.
- The setting controls the
+ The /> setting controls the
number of extra significant digits included when a floating point
value is converted to text for output. With the default value of
0 , the output is the same on every platform
This section describes a PostgreSQL-specific way to create an
autoincrementing column. Another way is to use the SQL-standard
- identity column feature, described at .
+ identity column feature, described at />.
from the sequence is still "used up" even if a row containing that
value is never successfully inserted into the table column. This
may happen, for example, if the inserting transaction rolls back.
- See nextval() in
+ See nextval() in />
for details.
The money type stores a currency amount with a fixed
fractional precision; see
- linkend="datatype-money-table">. The fractional precision is
- determined by the database's setting.
+ linkend="datatype-money-table"/ >. The fractional precision is
+ determined by the database's /> setting.
The range shown in the table assumes there are two fractional digits.
Input is accepted in a variety of formats, including integer and
floating-point literals, as well as typical
projects / postgresql.git / commitdiff