> For the complete documentation index, see [llms.txt](https://docs.postgresql.tw/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.postgresql.tw/internals/views/view-pg-settings.md). # 53.25. pg\_settings \# The view `pg_settings` provides access to run-time parameters of the server. It is essentially an alternative interface to the [`SHOW`](/reference/sql-commands/sql-show.md) and [`SET`](/reference/sql-commands/sql-set.md) commands. It also provides access to some facts about each parameter that are not directly available from [`SHOW`](/reference/sql-commands/sql-show.md), such as minimum and maximum values. **Table 53.25. `pg_settings` Columns** |

Column 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 user who neither is a superuser nor has privileges of pg\_read\_all\_settings); helpful when using include directives in configuration files

| |

sourceline int4

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 user who neither is a superuser nor has privileges of pg\_read\_all\_settings).

| |

pending\_restart bool

true if the value has been changed in the configuration file but needs a restart; or false otherwise.

|
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. `superuser-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), but only if the connecting user is a superuser or has been granted the appropriate `SET` privilege. 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. `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); any user can make such a change for their session. 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 and users with the appropriate `SET` privilege 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 their session-local value. Changes in `postgresql.conf` will affect existing sessions only if no session-local value has been established with `SET`. See [Section 19.1](/server-administration/runtime-config/config-setting.md) for more information about the various ways to change these parameters. This 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`. This view does not display [customized options](/server-administration/runtime-config/runtime-config-custom.md) unless the extension module that defines them has been loaded by the backend process executing the query (e.g., via a mention in [shared\_preload\_libraries](/server-administration/runtime-config/runtime-config-client.md#GUC-SHARED-PRELOAD-LIBRARIES), a call to a C function in the extension, or the [`LOAD`](/reference/sql-commands/sql-load.md) command). For example, since [archive modules](/server-programming/archive-modules.md) are normally loaded only by the archiver process not regular sessions, this view will not display any customized options defined by such modules unless special action is taken to load them into the backend process executing the query. *** 原文：[PostgreSQL 18.6 Documentation](https://www.postgresql.org/docs/18/view-pg-settings.html)（英文原文，待翻譯） --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.postgresql.tw/internals/views/view-pg-settings.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.