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.
This is used by initdb. This
parameter can only be set at server start.

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 parameter, 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.

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)

If nonzero, a delay of this many seconds occurs 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. This parameter cannot be changed after
session start.

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 procedure. This is intended to give
developers an opportunity to attach to the server process
with a debugger to trace down misbehavior in
authentication. 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:

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.