The following options are intended for work on the
PostgreSQL source, and in some cases
to assist with recovery of severely damaged databases. There
should be no reason to use them in a production database setup.
As such, they have been excluded from the sample
postgresql.conf
file. Note that many of these
options require special source compilation flags to work at all.
debug_assertions
(boolean
)
Turns on various assertion checks. This is a debugging aid. If
you are experiencing strange problems or crashes you might want
to turn this on, as it might expose programming mistakes. To use
this option, the macro USE_ASSERT_CHECKING
must be defined when PostgreSQL is
built (accomplished by the configure
option
--enable-cassert
). Note that
debug_assertions
defaults to on
if PostgreSQL has been built with
assertions enabled.
pre_auth_delay
(integer
)
If nonzero, a delay of this many seconds occurs just after a new server process is forked, before it conducts the authentication process. This is intended to give an opportunity to attach to the server process with a debugger to trace down misbehavior in authentication.
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 log, respectively.
trace_sort
(boolean
)
If on, emit information about resource usage during sort operations.
This option 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
)trace_lwlocks
(boolean
)trace_userlocks
(boolean
)trace_lock_oidmin
(boolean
)trace_lock_table
(boolean
)debug_deadlocks
(boolean
)log_btree_build_stats
(boolean
)
Various other code tracing and debugging options.
wal_debug
(boolean
)
If on, emit WAL-related debugging output. This option is
only available if the WAL_DEBUG
macro was
defined when PostgreSQL was
compiled.
zero_damaged_pages
(boolean
)
Detection of a damaged page header normally causes
PostgreSQL to report an error, aborting the current
command. Setting zero_damaged_pages
to on causes
the system to instead report a warning, zero out the damaged page,
and continue processing. This behavior will destroy data,
namely all the rows on the damaged page. But it allows you to get
past the error and retrieve rows from any undamaged pages that may
be present in the table. So it is useful for recovering data if
corruption has occurred due to hardware or software error. You should
generally not set this on until you have given up hope of recovering
data from the damaged page(s) of a table. The
default setting is off
, and it can only be changed
by a superuser.