PostgreSQL

  +
  Details of the structure being dumped may be found in `+src/include/storage/lock.h+`.
  +
  This parameter is only available if the `+LOCK_DEBUG+` macro was defined when PostgreSQL was compiled.
[.term]#`+trace_lwlocks+` (`+boolean+`)  link:runtime-config-developer.html#GUC-TRACE-LWLOCKS[#]::
  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 the `+LOCK_DEBUG+` macro was defined when PostgreSQL was compiled.
[.term]#`+trace_userlocks+` (`+boolean+`)  link:runtime-config-developer.html#GUC-TRACE-USERLOCKS[#]::
  If on, emit information about user lock usage. Output is the same as for `+trace_locks+`, only for advisory locks.
  +
  This parameter is only available if the `+LOCK_DEBUG+` macro was defined when PostgreSQL was compiled.
[.term]#`+trace_lock_oidmin+` (`+integer+`)  link:runtime-config-developer.html#GUC-TRACE-LOCK-OIDMIN[#]::
  If set, do not trace locks for tables below this OID (used to avoid output on system tables).
  +
  This parameter is only available if the `+LOCK_DEBUG+` macro was defined when PostgreSQL was compiled.
[.term]#`+trace_lock_table+` (`+integer+`)  link:runtime-config-developer.html#GUC-TRACE-LOCK-TABLE[#]::
  Unconditionally trace locks on this table (OID).
  +
  This parameter is only available if the `+LOCK_DEBUG+` macro was defined when PostgreSQL was compiled.
[.term]#`+debug_deadlocks+` (`+boolean+`)  link:runtime-config-developer.html#GUC-DEBUG-DEADLOCKS[#]::
  If set, dumps information about all current locks when a deadlock timeout occurs.
  +
  This parameter is only available if the `+LOCK_DEBUG+` macro was defined when PostgreSQL was compiled.
[.term]#`+log_btree_build_stats+` (`+boolean+`)  link:runtime-config-developer.html#GUC-LOG-BTREE-BUILD-STATS[#]::
  If set, logs system resource usage statistics (memory and CPU) on various B-tree operations.
  +
  This parameter is only available if the `+BTREE_BUILD_STATS+` macro was defined when PostgreSQL was compiled.
[.term]#`+wal_consistency_checking+` (`+string+`)  link:runtime-config-developer.html#GUC-WAL-CONSISTENCY-CHECKING[#]::
  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 to `+all+` 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 are `+heap+`, `+heap2+`, `+btree+`, `+hash+`, `+gin+`, `+gist+`, `+sequence+`, `+spgist+`, `+brin+`, and `+generic+`. Extensions may define additional resource managers. Only superusers and users with the appropriate `+SET+` privilege can change this setting.
[.term]#`+wal_debug+` (`+boolean+`)  link:runtime-config-developer.html#GUC-WAL-DEBUG[#]::
  If on, emit WAL-related debugging output. This parameter is only available if the `+WAL_DEBUG+` macro was defined when PostgreSQL was compiled.
[.term]#`+ignore_checksum_failure+` (`+boolean+`)  link:runtime-config-developer.html#GUC-IGNORE-CHECKSUM-FAILURE[#]::
  Only has effect if link:app-initdb.html#APP-INITDB-DATA-CHECKSUMS[data checksums] are enabled.
  +
  Detection of a checksum failure during a read normally causes PostgreSQL to report an error, aborting the current transaction. Setting `+ignore_checksum_failure+` to on causes the system to ignore the failure (but still report a warning), and continue processing. This behavior may [.emphasis]#_cause 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 is `+off+`. Only superusers and users with the appropriate `+SET+` privilege can change this setting.
[.term]#`+zero_damaged_pages+` (`+boolean+`)  link:runtime-config-developer.html#GUC-ZERO-DAMAGED-PAGES[#]::
  Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current transaction. Setting `+zero_damaged_pages+` to on causes the system to instead report a warning, zero out the damaged page in memory, and continue processing. This behavior [.emphasis]#_will 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 is `+off+`. Only superusers and users with the appropriate `+SET+` privilege can change this setting.
[.term]#`+ignore_invalid_pages+` (`+boolean+`)  link:runtime-config-developer.html#GUC-IGNORE-INVALID-PAGES[#]::
  If set to `+off+` (the default), detection of WAL records having references to invalid pages during recovery causes PostgreSQL to raise a PANIC-level error, aborting the recovery. Setting `+ignore_invalid_pages+` to `+on+` causes the system to ignore invalid page references in WAL records (but still report a warning), and continue the recovery. This behavior may [.emphasis]#_cause 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.
[.term]#`+jit_debugging_support+` (`+boolean+`)  link:runtime-config-developer.html#GUC-JIT-DEBUGGING-SUPPORT[#]::
  If LLVM has the required functionality, register generated functions with GDB. This makes debugging easier. The default setting is `+off+`. This parameter can only be set at server start.
[.term]#`+jit_dump_bitcode+` (`+boolean+`)  link:runtime-config-developer.html#GUC-JIT-DUMP-BITCODE[#]::
  Writes the generated LLVM IR out to the file system, inside link:runtime-config-file-locations.html#GUC-DATA-DIRECTORY[data_directory]. This is only useful for working on the internals of the JIT implementation. The default setting is `+off+`. Only superusers and users with the appropriate `+SET+` privilege can change this setting.
[.term]#`+jit_expressions+` (`+boolean+`)  link:runtime-config-developer.html#GUC-JIT-EXPRESSIONS[#]::
  Determines whether expressions are JIT compiled, when JIT compilation is activated (see link:jit-decision.html[Section 32.2]). The default is `+on+`.
[.term]#`+jit_profiling_support+` (`+boolean+`)  link:runtime-config-developer.html#GUC-JIT-PROFILING-SUPPORT[#]::
  If LLVM has the required functionality, emit the data needed to allow perf 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 is `+off+`. This parameter can only be set at server start.
[.term]#`+jit_tuple_deforming+` (`+boolean+`)  link:runtime-config-developer.html#GUC-JIT-TUPLE-DEFORMING[#]::
  Determines whether tuple deforming is JIT compiled, when JIT compilation is activated (see link:jit-decision.html[Section 32.2]). The default is `+on+`.
[.term]#`+remove_temp_files_after_crash+` (`+boolean+`)  link:runtime-config-developer.html#GUC-REMOVE-TEMP-FILES-AFTER-CRASH[#]::
  When set to `+on+`, 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 the `+postgresql.conf+` file or on the server command line.
[.term]#`+send_abort_for_crash+` (`+boolean+`)  link:runtime-config-developer.html#GUC-SEND-ABORT-FOR-CRASH[#]::
  By default, after a backend crash the postmaster will stop remaining child processes by sending them [.systemitem]#SIGQUIT# signals, which permits them to exit more-or-less gracefully. When this option is set to `+on+`, [.systemitem]#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 the `+postgresql.conf+` file or on the server command line.
[.term]#`+send_abort_for_kill+` (`+boolean+`)  link:runtime-config-developer.html#GUC-SEND-ABORT-FOR-KILL[#]::
  By default, after attempting to stop a child process with [.systemitem]#SIGQUIT#, the postmaster will wait five seconds and then send [.systemitem]#SIGKILL# to force immediate termination. When this option is set to `+on+`, [.systemitem]#SIGABRT# is sent instead of [.systemitem]#SIGKILL#. That normally results in production of a core dump file for each such child process. This can be handy for investigating the states of [.quote]#“[.quote]#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 the `+postgresql.conf+` file or on the server command line.
[.term]#`+debug_logical_replication_streaming+` (`+enum+`)  link:runtime-config-developer.html#GUC-DEBUG-LOGICAL-REPLICATION-STREAMING[#]::
  The allowed values are `+buffered+` and `+immediate+`. The default is `+buffered+`. This parameter is intended to be used to test logical decoding and replication of large transactions. The effect of `+debug_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 to `+immediate+`, stream each change if the link:sql-createsubscription.html#SQL-CREATESUBSCRIPTION-WITH-STREAMING[`+streaming+`] option of link:sql-createsubscription.html[`+CREATE SUBSCRIPTION+`] is enabled, otherwise, serialize each change. When set to `+buffered+`, the decoding will stream or serialize changes when `+logical_decoding_work_mem+` is reached.
  +
  On the subscriber side, if the `+streaming+` option is set to `+parallel+`, `+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 to `+buffered+`, the leader sends changes to parallel apply workers via a shared memory queue. When set to `+immediate+`, the leader serializes all changes to files and notifies the parallel apply workers to read and apply them at the end of the transaction.