Movatterモバイル変換

Allows tablespaces to be created as directories insidepg_tblspc, when an empty location string is provided to theCREATE TABLESPACE command. This is intended to allow testing replication scenarios where primary and standby servers are running on the same machine. Such directories are likely to confuse backup tools that expect to find only symbolic links in that location. Only superusers and users with the appropriateSET privilege can change this setting.

Allows modification of the structure of system tables as well as certain other risky actions on system tables. This is otherwise not allowed even for superusers. Ill-advised use of this setting can cause irretrievable data loss or seriously corrupt the database system. Only superusers and users with the appropriateSET privilege can change this setting.

This parameter contains a comma-separated list of C function names. If an error is raised and the name of the internal C function where the error happens matches a value in the list, then a backtrace is written to the server log together with the error message. This can be used to debug specific areas of the source code.

Backtrace support is not available on all platforms, and the quality of the backtraces depends on compilation options.

Only superusers and users with the appropriateSET privilege can change this setting.

When set to1, each system catalog cache entry is invalidated at the first possible opportunity, whether or not anything that would render it invalid really occurred. Caching of system catalogs is effectively disabled as a result, so the server will run extremely slowly. Higher values run the cache invalidation recursively, which is even slower and only useful for testing the caching logic itself. The default value of0 selects normal catalog caching behavior.

This parameter can be very helpful when trying to trigger hard-to-reproduce bugs involving concurrent catalog changes, but it is otherwise rarely needed. See the source code filesinval.c andpg_config_manual.h for details.

This parameter is supported whenDISCARD_CACHES_ENABLED was defined at compile time (which happens automatically when using theconfigure option--enable-cassert). In production builds, its value will always be0 and attempts to set it to another value will raise an error.

Ask the kernel to minimize caching effects for relation data and WAL files usingO_DIRECT (most Unix-like systems),F_NOCACHE (macOS) orFILE_FLAG_NO_BUFFERING (Windows).

May be set to an empty string (the default) to disable use of direct I/O, or a comma-separated list of operations that should use direct I/O. The valid options aredata for main data files,wal for WAL files, andwal_init for WAL files when being initially allocated.

Some operating systems and file systems do not support direct I/O, so non-default settings may be rejected at startup or cause errors.

Currently this feature reduces performance, and is intended for developer testing only.

Allows the use of parallel queries for testing purposes even in cases where no performance benefit is expected. The allowed values ofdebug_parallel_query areoff (use parallel mode only when it is expected to improve performance),on (force parallel query for all queries for which it is thought to be safe), andregress (likeon, but with additional behavior changes as explained below).

More specifically, setting this value toon will add aGather node to the top of any query plan for which this appears to be safe, so that the query runs inside of a parallel worker. Even when a parallel worker is not available or cannot be used, operations such as starting a subtransaction that would be prohibited in a parallel query context will be prohibited unless the planner believes that this will cause the query to fail. If failures or unexpected results occur when this option is set, some functions used by the query may need to be markedPARALLEL UNSAFE (or, possibly,PARALLEL RESTRICTED).

Setting this value toregress has all of the same effects as setting it toon plus some additional effects that are intended to facilitate automated regression testing. Normally, messages from a parallel worker include a context line indicating that, but a setting ofregress suppresses this line so that the output is the same as in non-parallel execution. Also, theGather nodes added to plans by this setting are hidden inEXPLAIN output so that the output matches what would be obtained if this setting were turnedoff.

Ignore system indexes when reading system tables (but still update the indexes when modifying the tables). This is useful when recovering from damaged system indexes. This parameter cannot be changed after session start.

The amount of time to delay when a new server process is started, after it conducts the authentication procedure. This is intended to give developers an opportunity to attach to the server process with a debugger. If this value is specified without units, it is taken as seconds. A value of zero (the default) disables the delay. This parameter cannot be changed after session start.

The amount of time to delay just after a new server process is forked, before it conducts the authentication procedure. This is intended to give developers an opportunity to attach to the server process with a debugger to trace down misbehavior in authentication. If this value is specified without units, it is taken as seconds. A value of zero (the default) disables the delay. This parameter can only be set in thepostgresql.conf file or on the server command line.

Generates a great amount of debugging output for theLISTEN andNOTIFY commands.client_min_messages orlog_min_messages must beDEBUG1 or lower to send this output to the client or server logs, respectively.

If on, emit information about resource usage during sort operations. This parameter is only available if theTRACE_SORT macro was defined whenPostgreSQL was compiled. (However,TRACE_SORT is currently defined by default.)

If on, emit information about lock usage. Information dumped includes the type of lock operation, the type of lock and the unique identifier of the object being locked or unlocked. Also included are bit masks for the lock types already granted on this object as well as for the lock types awaited on this object. For each lock type a count of the number of granted locks and waiting locks is also dumped as well as the totals. An example of the log file output is shown here:

LOG:  LockAcquire: new: lock(0xb7acd844) id(24688,24696,0,0,0,1)      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0      wait(0) type(AccessShareLock)LOG:  GrantLock: lock(0xb7acd844) id(24688,24696,0,0,0,1)      grantMask(2) req(1,0,0,0,0,0,0)=1 grant(1,0,0,0,0,0,0)=1      wait(0) type(AccessShareLock)LOG:  UnGrantLock: updated: lock(0xb7acd844) id(24688,24696,0,0,0,1)      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0      wait(0) type(AccessShareLock)LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0      wait(0) type(INVALID)

Details of the structure being dumped may be found insrc/include/storage/lock.h.

This parameter is only available if theLOCK_DEBUG macro was defined whenPostgreSQL was compiled.

If on, emit information about lightweight lock usage. Lightweight locks are intended primarily to provide mutual exclusion of access to shared-memory data structures.

This parameter is only available if theLOCK_DEBUG macro was defined whenPostgreSQL was compiled.

If on, emit information about user lock usage. Output is the same as fortrace_locks, only for advisory locks.

This parameter is only available if theLOCK_DEBUG macro was defined whenPostgreSQL was compiled.

If set, do not trace locks for tables below this OID (used to avoid output on system tables).

This parameter is only available if theLOCK_DEBUG macro was defined whenPostgreSQL was compiled.

Unconditionally trace locks on this table (OID).

This parameter is only available if theLOCK_DEBUG macro was defined whenPostgreSQL was compiled.

If set, dumps information about all current locks when a deadlock timeout occurs.

This parameter is only available if theLOCK_DEBUG macro was defined whenPostgreSQL was compiled.

If set, logs system resource usage statistics (memory and CPU) on various B-tree operations.

This parameter is only available if theBTREE_BUILD_STATS macro was defined whenPostgreSQL was compiled.

This parameter is intended to be used to check for bugs in the WAL redo routines. When enabled, full-page images of any buffers modified in conjunction with the WAL record are added to the record. If the record is subsequently replayed, the system will first apply each record and then test whether the buffers modified by the record match the stored images. In certain cases (such as hint bits), minor variations are acceptable, and will be ignored. Any unexpected differences will result in a fatal error, terminating recovery.

The default value of this setting is the empty string, which disables the feature. It can be set toall to check all records, or to a comma-separated list of resource managers to check only records originating from those resource managers. Currently, the supported resource managers areheap,heap2,btree,hash,gin,gist,sequence,spgist,brin, andgeneric. Extensions may define additional resource managers. Only superusers and users with the appropriateSET privilege can change this setting.

If on, emit WAL-related debugging output. This parameter is only available if theWAL_DEBUG macro was defined whenPostgreSQL was compiled.

Only has effect ifdata checksums are enabled.

Detection of a checksum failure during a read normally causesPostgreSQL to report an error, aborting the current transaction. Settingignore_checksum_failure to on causes the system to ignore the failure (but still report a warning), and continue processing. This behavior maycause crashes, propagate or hide corruption, or other serious problems. However, it may allow you to get past the error and retrieve undamaged tuples that might still be present in the table if the block header is still sane. If the header is corrupt an error will be reported even if this option is enabled. The default setting isoff. Only superusers and users with the appropriateSET privilege can change this setting.

Detection of a damaged page header normally causesPostgreSQL to report an error, aborting the current transaction. Settingzero_damaged_pages to on causes the system to instead report a warning, zero out the damaged page in memory, and continue processing. This behaviorwill destroy data, namely all the rows on the damaged page. However, it does allow you to get past the error and retrieve rows from any undamaged pages that might be present in the table. It is useful for recovering data if corruption has occurred due to a hardware or software error. You should generally not set this on until you have given up hope of recovering data from the damaged pages of a table. Zeroed-out pages are not forced to disk so it is recommended to recreate the table or the index before turning this parameter off again. The default setting isoff. Only superusers and users with the appropriateSET privilege can change this setting.

If set tooff (the default), detection of WAL records having references to invalid pages during recovery causesPostgreSQL to raise a PANIC-level error, aborting the recovery. Settingignore_invalid_pages toon causes the system to ignore invalid page references in WAL records (but still report a warning), and continue the recovery. This behavior maycause crashes, data loss, propagate or hide corruption, or other serious problems. However, it may allow you to get past the PANIC-level error, to finish the recovery, and to cause the server to start up. The parameter can only be set at server start. It only has effect during recovery or in standby mode.

If LLVM has the required functionality, register generated functions withGDB. This makes debugging easier. The default setting isoff. This parameter can only be set at server start.

Writes the generatedLLVM IR out to the file system, insidedata_directory. This is only useful for working on the internals of the JIT implementation. The default setting isoff. Only superusers and users with the appropriateSET privilege can change this setting.

Determines whether expressions are JIT compiled, when JIT compilation is activated (seeSection 30.2). The default ison.

If LLVM has the required functionality, emit the data needed to allowperf to profile functions generated by JIT. This writes out files to~/.debug/jit/; the user is responsible for performing cleanup when desired. The default setting isoff. This parameter can only be set at server start.

Determines whether tuple deforming is JIT compiled, when JIT compilation is activated (seeSection 30.2). The default ison.

When set toon, which is the default,PostgreSQL will automatically remove temporary files after a backend crash. If disabled, the files will be retained and may be used for debugging, for example. Repeated crashes may however result in accumulation of useless files. This parameter can only be set in thepostgresql.conf file or on the server command line.

By default, after a backend crash the postmaster will stop remaining child processes by sending themSIGQUIT signals, which permits them to exit more-or-less gracefully. When this option is set toon,SIGABRT is sent instead. That normally results in production of a core dump file for each such child process. This can be handy for investigating the states of other processes after a crash. It can also consume lots of disk space in the event of repeated crashes, so do not enable this on systems you are not monitoring carefully. Beware that no support exists for cleaning up the core file(s) automatically. This parameter can only be set in thepostgresql.conf file or on the server command line.

By default, after attempting to stop a child process withSIGQUIT, the postmaster will wait five seconds and then sendSIGKILL to force immediate termination. When this option is set toon,SIGABRT is sent instead ofSIGKILL. That normally results in production of a core dump file for each such child process. This can be handy for investigating the states of“stuck” child processes. It can also consume lots of disk space in the event of repeated crashes, so do not enable this on systems you are not monitoring carefully. Beware that no support exists for cleaning up the core file(s) automatically. This parameter can only be set in thepostgresql.conf file or on the server command line.

The allowed values arebuffered andimmediate. The default isbuffered. This parameter is intended to be used to test logical decoding and replication of large transactions. The effect ofdebug_logical_replication_streaming is different for the publisher and subscriber:

On the publisher side,debug_logical_replication_streaming allows streaming or serializing changes immediately in logical decoding. When set toimmediate, stream each change if thestreaming option ofCREATE SUBSCRIPTION is enabled, otherwise, serialize each change. When set tobuffered, the decoding will stream or serialize changes whenlogical_decoding_work_mem is reached.

On the subscriber side, if thestreaming option is set toparallel,debug_logical_replication_streaming can be used to direct the leader apply worker to send changes to the shared memory queue or to serialize all changes to the file. When set tobuffered, the leader sends changes to parallel apply workers via a shared memory queue. When set toimmediate, the leader serializes all changes to files and notifies the parallel apply workers to read and apply them at the end of the transaction.