The following parameters are intended for work on the
PostgreSQL source code, and in some cases
to assist with recovery of severely damaged databases. There
should be no reason to use them on a production database.
As such, they have been excluded from the sample
postgresql.conf
file. Note that many of these
parameters require special source compilation flags to work at all.
allow_system_table_mods
(boolean
)
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 can change this setting.
backtrace_functions
(string
)
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.
This parameter can only be set by superusers.
ignore_system_indexes
(boolean
)
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.
post_auth_delay
(integer
)
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.
pre_auth_delay
(integer
)
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 the postgresql.conf
file or on the server command line.
trace_notify
(boolean
)
Generates a great amount of debugging output for the
LISTEN
and NOTIFY
commands. client_min_messages or
log_min_messages must be
DEBUG1
or lower to send this output to the
client or server logs, respectively.
trace_recovery_messages
(enum
)
Enables logging of recovery-related debugging output that otherwise
would not be logged. This parameter allows the user to override the
normal setting of log_min_messages, but only for
specific messages. This is intended for use in debugging Hot Standby.
Valid values are DEBUG5
, DEBUG4
,
DEBUG3
, DEBUG2
, DEBUG1
, and
LOG
. The default, LOG
, does not affect
logging decisions at all. The other values cause recovery-related
debug messages of that priority or higher to be logged as though they
had LOG
priority; for common settings of
log_min_messages
this results in unconditionally sending
them to the server log.
This parameter can only be set in the postgresql.conf
file or on the server command line.
trace_sort
(boolean
)
If on, emit information about resource usage during sort operations.
This parameter is only available if the TRACE_SORT
macro
was defined when PostgreSQL was compiled.
(However, TRACE_SORT
is currently defined by default.)
trace_locks
(boolean
)
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 in
src/include/storage/lock.h
.
This parameter is only available if the LOCK_DEBUG
macro was defined when PostgreSQL was
compiled.
trace_lwlocks
(boolean
)
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.
trace_userlocks
(boolean
)
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.
trace_lock_oidmin
(integer
)
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.
trace_lock_table
(integer
)
Unconditionally trace locks on this table (OID).
This parameter is only available if the LOCK_DEBUG
macro was defined when PostgreSQL was
compiled.
debug_deadlocks
(boolean
)
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.
log_btree_build_stats
(boolean
)
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.
wal_consistency_checking
(string
)
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
. Only
superusers can change this setting.
wal_debug
(boolean
)
If on, emit WAL-related debugging output. This parameter is
only available if the WAL_DEBUG
macro was
defined when PostgreSQL was
compiled.
ignore_checksum_failure
(boolean
)
Only has effect if 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 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
, and it can only be changed by a superuser.
zero_damaged_pages
(boolean
)
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 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
, and it can only be changed
by a superuser.
ignore_invalid_pages
(boolean
)
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 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.
jit_debugging_support
(boolean
)
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.
jit_dump_bitcode
(boolean
)
Writes the generated LLVM IR out to the
file system, inside data_directory. This is only
useful for working on the internals of the JIT implementation.
The default setting is off
.
This parameter can only be changed by a superuser.
jit_expressions
(boolean
)
Determines whether expressions are JIT compiled, when JIT compilation
is activated (see Section 31.2). The default is
on
.
jit_profiling_support
(boolean
)
If LLVM has the required functionality, emit the data needed to allow
perf to profile functions generated by JIT.
This writes out files to $HOME/.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.
jit_tuple_deforming
(boolean
)
Determines whether tuple deforming is JIT compiled, when JIT
compilation is activated (see Section 31.2).
The default is on
.