Movatterモバイル変換

Controls whichmessage levels are sent to the client. Valid values areDEBUG5,DEBUG4,DEBUG3,DEBUG2,DEBUG1,LOG,NOTICE,WARNING, andERROR. Each level includes all the levels that follow it. The later the level, the fewer messages are sent. The default isNOTICE. Note thatLOG has a different rank here than inlog_min_messages.

INFO level messages are always sent to the client.

This variable specifies the order in which schemas are searched when an object (table, data type, function, etc.) is referenced by a simple name with no schema specified. When there are objects of identical names in different schemas, the one found first in the search path is used. An object that is not in any of the schemas in the search path can only be referenced by specifying its containing schema with a qualified (dotted) name.

The value forsearch_path must be a comma-separated list of schema names. Any name that is not an existing schema, or is a schema for which the user does not haveUSAGE permission, is silently ignored.

If one of the list items is the special name$user, then the schema having the name returned byCURRENT_USER is substituted, if there is such a schema and the user hasUSAGE permission for it. (If not,$user is ignored.)

The system catalog schema,pg_catalog, is always searched, whether it is mentioned in the path or not. If it is mentioned in the path then it will be searched in the specified order. Ifpg_catalog is not in the path then it will be searchedbefore searching any of the path items.

Likewise, the current session's temporary-table schema,pg_temp_nnn, is always searched if it exists. It can be explicitly listed in the path by using the aliaspg_temp. If it is not listed in the path then it is searched first (even beforepg_catalog). However, the temporary schema is only searched for relation (table, view, sequence, etc) and data type names. It is never searched for function or operator names.

When objects are created without specifying a particular target schema, they will be placed in the first valid schema named insearch_path. An error is reported if the search path is empty.

The default value for this parameter is"$user", public. This setting supports shared use of a database (where no users have private schemas, and all share use ofpublic), private per-user schemas, and combinations of these. Other effects can be obtained by altering the default search path setting, either globally or per-user.

For more information on schema handling, seeSection 5.8. In particular, the default configuration is suitable only when the database has a single user or a few mutually-trusting users.

The current effective value of the search path can be examined via theSQL functioncurrent_schemas (seeSection 9.25). This is not quite the same as examining the value ofsearch_path, sincecurrent_schemas shows how the items appearing insearch_path were resolved.

This variable controls whether to raise an error in lieu of applying a row security policy. When set toon, policies apply normally. When set tooff, queries fail which would otherwise apply at least one policy. The default ison. Change tooff where limited row visibility could cause incorrect results; for example,pg_dump makes that change by default. This variable has no effect on roles which bypass every row security policy, to wit, superusers and roles with theBYPASSRLS attribute.

For more information on row security policies, seeCREATE POLICY.

This variable specifies the default tablespace in which to create objects (tables and indexes) when aCREATE command does not explicitly specify a tablespace.

The value is either the name of a tablespace, or an empty string to specify using the default tablespace of the current database. If the value does not match the name of any existing tablespace,PostgreSQL will automatically use the default tablespace of the current database. If a nondefault tablespace is specified, the user must haveCREATE privilege for it, or creation attempts will fail.

This variable is not used for temporary tables; for them,temp_tablespaces is consulted instead.

This variable is also not used when creating databases. By default, a new database inherits its tablespace setting from the template database it is copied from.

For more information on tablespaces, seeSection 21.6.

This variable specifies tablespaces in which to create temporary objects (temp tables and indexes on temp tables) when aCREATE command does not explicitly specify a tablespace. Temporary files for purposes such as sorting large data sets are also created in these tablespaces.

The value is a list of names of tablespaces. When there is more than one name in the list,PostgreSQL chooses a random member of the list each time a temporary object is to be created; except that within a transaction, successively created temporary objects are placed in successive tablespaces from the list. If the selected element of the list is an empty string,PostgreSQL will automatically use the default tablespace of the current database instead.

Whentemp_tablespaces is set interactively, specifying a nonexistent tablespace is an error, as is specifying a tablespace for which the user does not haveCREATE privilege. However, when using a previously set value, nonexistent tablespaces are ignored, as are tablespaces for which the user lacksCREATE privilege. In particular, this rule applies when using a value set inpostgresql.conf.

The default value is an empty string, which results in all temporary objects being created in the default tablespace of the current database.

See alsodefault_tablespace.

This parameter is normally on. When set tooff, it disables validation of the function body string duringCREATE FUNCTION. Disabling validation avoids side effects of the validation process and avoids false positives due to problems such as forward references. Set this parameter tooff before loading functions on behalf of other users;pg_dump does so automatically.

Each SQL transaction has an isolation level, which can be either“read uncommitted”,“read committed”,“repeatable read”, or“serializable”. This parameter controls the default isolation level of each new transaction. The default is“read committed”.

ConsultChapter 13 andSET TRANSACTION for more information.

A read-only SQL transaction cannot alter non-temporary tables. This parameter controls the default read-only status of each new transaction. The default isoff (read/write).

ConsultSET TRANSACTION for more information.

When running at theserializable isolation level, a deferrable read-only SQL transaction may be delayed before it is allowed to proceed. However, once it begins executing it does not incur any of the overhead required to ensure serializability; so serialization code will have no reason to force it to abort because of concurrent updates, making this option suitable for long-running read-only transactions.

This parameter controls the default deferrable status of each new transaction. It currently has no effect on read-write transactions or those operating at isolation levels lower thanserializable. The default isoff.

ConsultSET TRANSACTION for more information.

Controls firing of replication-related triggers and rules for the current session. Setting this variable requires superuser privilege and results in discarding any previously cached query plans. Possible values areorigin (the default),replica andlocal. SeeALTER TABLE for more information.

Abort any statement that takes more than the specified number of milliseconds, starting from the time the command arrives at the server from the client. Iflog_min_error_statement is set toERROR or lower, the statement that timed out will also be logged. A value of zero (the default) turns this off.

Settingstatement_timeout inpostgresql.conf is not recommended because it would affect all sessions.

Abort any statement that waits longer than the specified number of milliseconds while attempting to acquire a lock on a table, index, row, or other database object. The time limit applies separately to each lock acquisition attempt. The limit applies both to explicit locking requests (such asLOCK TABLE, orSELECT FOR UPDATE withoutNOWAIT) and to implicitly-acquired locks. A value of zero (the default) turns this off.

Unlikestatement_timeout, this timeout can only occur while waiting for locks. Note that ifstatement_timeout is nonzero, it is rather pointless to setlock_timeout to the same or larger value, since the statement timeout would always trigger first. Iflog_min_error_statement is set toERROR or lower, the statement that timed out will be logged.

Settinglock_timeout inpostgresql.conf is not recommended because it would affect all sessions.

VACUUM performs a whole-table scan if the table'spg_class.relfrozenxid field has reached the age specified by this setting. 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% ofautovacuum_freeze_max_age, so that a periodical manualVACUUM has a chance to run before an anti-wraparound autovacuum is launched for the table. For more information seeSection 23.1.5.

Specifies the cutoff age (in transactions) thatVACUUM should use to decide whether to freeze row versions while scanning a table. 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 ofautovacuum_freeze_max_age, so that there is not an unreasonably short time between forced autovacuums. For more information seeSection 23.1.5.

VACUUM performs a whole-table scan if the table'spg_class.relminmxid field has reached the age specified by this setting. 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% ofautovacuum_multixact_freeze_max_age, so that a periodical manualVACUUM has a chance to run before an anti-wraparound is launched for the table. For more information seeSection 23.1.5.1.

Specifies the cutoff age (in multixacts) thatVACUUM should use to decide whether to replace multixact IDs with a newer transaction ID or multixact ID while scanning a table. The default 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 ofautovacuum_multixact_freeze_max_age, so that there is not an unreasonably short time between forced autovacuums. For more information seeSection 23.1.5.1.

Sets the output format for values of typebytea. Valid values arehex (the default) andescape (the traditional PostgreSQL format). SeeSection 8.4 for more information. Thebytea type always accepts both formats on input, regardless of this setting.

Sets how binary values are to be encoded in XML. This applies for example whenbytea values are converted to XML by the functionsxmlelement orxmlforest. Possible values arebase64 andhex, which are both defined in the XML Schema standard. The default isbase64. For further information about XML-related functions, seeSection 9.14.

The actual choice here is mostly a matter of taste, constrained only by possible restrictions in client applications. Both methods support all possible values, although the hex encoding will be somewhat larger than the base64 encoding.

Sets whetherDOCUMENT orCONTENT is implicit when converting between XML and character string values. SeeSection 8.13 for a description of this. Valid values areDOCUMENT andCONTENT. The default isCONTENT.

According to the SQL standard, the command to set this option is

SET XML OPTION { DOCUMENT | CONTENT };

This syntax is also available in PostgreSQL.

Sets the maximum size of the GIN pending list which is used whenfastupdate is enabled. If the list grows larger than this maximum size, it is cleaned up by moving the entries in it to the main GIN data structure in bulk. The default is four megabytes (4MB). This setting can be overridden for individual GIN indexes by changing index storage parameters. SeeSection 61.4.1 andSection 61.5 for more information.

Sets the display format for date and time values, as well as the rules for interpreting ambiguous date input values. For historical reasons, this variable contains two independent components: the output format specification (ISO,Postgres,SQL, orGerman) and the input/output specification for year/month/day ordering (DMY,MDY, orYMD). These can be set separately or together. The keywordsEuro andEuropean are synonyms forDMY; the keywordsUS,NonEuro, andNonEuropean are synonyms forMDY. SeeSection 8.5 for more information. The built-in default isISO, MDY, butinitdb will initialize the configuration file with a setting that corresponds to the behavior of the chosenlc_time locale.

Sets the display format for interval values. The valuesql_standard will produce output matchingSQL standard interval literals. The valuepostgres (which is the default) will produce output matchingPostgreSQL releases prior to 8.4 when theDateStyle parameter was set toISO. The valuepostgres_verbose will produce output matchingPostgreSQL releases prior to 8.4 when theDateStyle parameter was set to non-ISO output. The valueiso_8601 will produce output matching the time interval“format with designators” defined in section 4.4.3.2 of ISO 8601.

TheIntervalStyle parameter also affects the interpretation of ambiguous interval input. SeeSection 8.5.4 for more information.

Sets the time zone for displaying and interpreting time stamps. The built-in default isGMT, but that is typically overridden inpostgresql.conf;initdb will install a setting there corresponding to its system environment. SeeSection 8.5.3 for more information.

Sets the collection of time zone abbreviations that will be accepted by the server for datetime input. The default is'Default', 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. SeeSection B.4 for more information.

This parameter adjusts the number of digits displayed for floating-point values, includingfloat4,float8, and geometric data types. The parameter value is added to the standard number of digits (FLT_DIG orDBL_DIG as appropriate). The value can be set as high as 3, to include 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 alsoSection 8.1.3.

Sets the client-side encoding (character set). The default is to use the database encoding. The character sets supported by thePostgreSQL server are described inSection 22.3.1.

Sets the language in which messages are displayed. Acceptable values are system-dependent; seeSection 22.1 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.

On some systems, this locale category does not exist. Setting this variable will still work, but there will be no effect. Also, there is a chance that no translated messages for the desired language exist. In that case you will continue to see the English messages.

Only superusers can change this setting, because it affects the messages sent to the server log as well as to the client, and an improper value might obscure the readability of the server logs.

Sets the locale to use for formatting monetary amounts, for example with theto_char family of functions. Acceptable values are system-dependent; seeSection 22.1 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 theto_char family of functions. Acceptable values are system-dependent; seeSection 22.1 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 theto_char family of functions. Acceptable values are system-dependent; seeSection 22.1 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. SeeChapter 12 for further information. The built-in default ispg_catalog.simple, butinitdb will initialize the configuration file with a setting that corresponds to the chosenlc_ctype locale, if a configuration matching that locale can be identified.

This variable specifies one or more shared libraries that are to be preloaded at connection start. The parameter value only takes effect at the start of the connection. Subsequent changes have no effect. If a specified library is not found, the connection attempt will fail.

This option can be set by any user. Because of that, the libraries that can be loaded are restricted to those appearing in theplugins subdirectory of the installation's standard library directory. (It is the database administrator's responsibility to ensure that only“safe” libraries are installed there.) Entries inlocal_preload_libraries can specify this directory explicitly, for example$libdir/plugins/mylib, or just specify the library name —mylib would have the same effect as$libdir/plugins/mylib.

The intent of this feature is to allow unprivileged users to load debugging or performance-measurement libraries into specific sessions without requiring an explicitLOAD command. To that end, it would be typical to set this parameter using thePGOPTIONS environment variable on the client or by usingALTER ROLE SET.

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 atsession_preload_libraries instead.

This variable specifies one or more shared libraries that are to be preloaded at connection start. Only superusers can change this setting. The parameter value only takes effect at the start of the connection. Subsequent changes have no effect. If a specified library is not found, the connection attempt will fail.

The intent of this feature is to allow debugging or performance-measurement libraries to be loaded into specific sessions without an explicitLOAD command being given. For example,auto_explain could be enabled for all sessions under a given user name by setting this parameter withALTER ROLE SET. Also, this parameter can be changed without restarting the server (but changes only take effect when a new session is started), so it is easier to add new modules this way, even if they should apply to all sessions.

Unlikeshared_preload_libraries, 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. This parameter can only be set at server start. If a specified library is not found, the server will fail to start.

Some libraries need to perform certain operations that can only take place at postmaster start, such as allocating shared memory, reserving light-weight locks, or starting background workers. Those libraries must be loaded at server start through this parameter. See the documentation of each library for details.

Other libraries can also be preloaded. By preloading a shared library, the library startup time is avoided when the library is first used. However, the time to start each new server process might increase slightly, even if that process never uses the library. So this 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. Usesession_preload_libraries for that instead.

If a dynamically loadable module needs to be opened and the file name specified in theCREATE FUNCTION orLOAD command does not have a directory component (i.e., the name does not contain a slash), the system will search this path for the required file.

The value fordynamic_library_path must be a list of absolute directory paths separated by colons (or semi-colons on Windows). If a list element starts with the special string$libdir, the compiled-inPostgreSQL package library directory is substituted for$libdir; this is where the modules provided by the standardPostgreSQL distribution are installed. (Usepg_config --pkglibdir to find out the name of this directory.) For example:

dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'

or, in a Windows environment:

dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'

The default value for this parameter is'$libdir'. If the value is set to an empty string, the automatic path search is turned off.

This parameter can be changed at run time by superusers, but a setting done that way will only persist until the end of the client connection, so this method should be reserved for development purposes. The recommended way to set this parameter is in thepostgresql.conf configuration file.

Soft upper limit of the size of the set returned by GIN index scans. For more information seeSection 61.5.