The view pg_settings provides access to
run-time parameters of the server. It is essentially an alternative
interface to the SHOW
and SET commands.
It also provides access to some facts about each parameter that are
not directly available from SHOW, such as minimum and
maximum values.
Table 45-63. pg_settings Columns
| Name | Type | Description |
|---|
| name | text | Run-time configuration parameter name |
| setting | text | Current value of the parameter |
| unit | text | Implicit unit of the parameter |
| category | text | Logical group of the parameter |
| short_desc | text | A brief description of the parameter |
| extra_desc | text | Additional, more detailed, description of the parameter |
| context | text | Context required to set the parameter's value (see below) |
| vartype | text | Parameter type (bool, enum,
integer, real, or string)
|
| source | text | Source of the current parameter value |
| min_val | text | Minimum allowed value of the parameter (null for non-numeric
values) |
| max_val | text | Maximum allowed value of the parameter (null for non-numeric
values) |
| enumvals | text[] | Allowed values of an enum parameter (null for non-enum
values) |
| boot_val | text | Parameter value assumed at server startup if the parameter is
not otherwise set |
| reset_val | text | Value that RESET would reset the parameter to
in the current session |
| sourcefile | text | Configuration file the current value was set in (null for
values set from sources other than configuration files, or when
examined by a non-superuser);
helpful when using include directives in configuration files |
| sourceline | integer | Line number within the configuration file the current value was
set at (null for values set from sources other than configuration files,
or when examined by a non-superuser)
|
There are several possible values of context.
In order of decreasing difficulty of changing the setting, they are:
- internal
These settings cannot be changed directly; they reflect internally
determined values. Some of them may be adjustable by rebuilding the
server with different configuration options, or by changing options
supplied to initdb.
- postmaster
These settings can only be applied when the server starts, so any change
requires restarting the server. Values for these settings are typically
stored in the postgresql.conf file, or passed on
the command line when starting the server. Of course, settings with any
of the lower context types can also be
set at server start time.
- sighup
Changes to these settings can be made in
postgresql.conf without restarting the server.
Send a SIGHUP signal to the postmaster to
cause it to re-read postgresql.conf and apply
the changes. The postmaster will also forward the
SIGHUP signal to its child processes so that
they all pick up the new value.
- backend
Changes to these settings can be made in
postgresql.conf without restarting the server;
they can also be set for a particular session in the connection request
packet (for example, via libpq's PGOPTIONS
environment variable). However, these settings never change in a
session after it is started. If you change them in
postgresql.conf, send a
SIGHUP signal to the postmaster to cause it to
re-read postgresql.conf. The new values will only
affect subsequently-launched sessions.
- superuser
These settings can be set from postgresql.conf,
or within a session via the SET command; but only superusers
can change them via SET. Changes in
postgresql.conf will affect existing sessions
only if no session-local value has been established with SET.
- user
These settings can be set from postgresql.conf,
or within a session via the SET command. Any user is
allowed to change his session-local value. Changes in
postgresql.conf will affect existing sessions
only if no session-local value has been established with SET.
See Section 18.1 for more information about the various
ways to change these parameters.
The pg_settings view cannot be inserted into or
deleted from, but it can be updated. An UPDATE applied
to a row of pg_settings is equivalent to executing
the SET command on that named
parameter. The change only affects the value used by the current
session. If an UPDATE is issued within a transaction
that is later aborted, the effects of the UPDATE command
disappear when the transaction is rolled back. Once the surrounding
transaction is committed, the effects will persist until the end of the
session, unless overridden by another UPDATE or
SET.