|PostgreSQL Reference Manual - Volume 3 - Server Administration Guide|
by The PostgreSQL Global Development Group
Paperback (6"x9"), 204 pages
RRP £13.95 ($24.95)
Sales of this book support the PostgreSQL project! Get a printed copy>>>
4.15 Developer Options
The following parameters 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 parameters require special source compilation flags to work at all.
Allows modification of the structure of system tables.
This is used by
initdb. This parameter can only be set at server start.
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_CHECKINGmust be defined when PostgreSQL is built (accomplished by the
--enable-cassert). Note that
onif PostgreSQL has been built with assertions enabled.
- 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.
- 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 an opportunity to attach to the server process with a debugger. This parameter cannot be changed after session start.
- 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 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.
Generates a great amount of debugging output for the
DEBUG1or lower to send this output to the client or server log, respectively.
If on, emit information about resource usage during sort operations.
This parameter is only available if the
TRACE_SORTmacro was defined when PostgreSQL was compiled. (However,
TRACE_SORTis currently defined by default.)
- Various other code tracing and debugging options.
If on, emit WAL-related debugging output. This parameter is
only available if the
WAL_DEBUGmacro was defined when PostgreSQL was compiled.
Detection of a damaged page header normally causes
PostgreSQL to report an error, aborting the current
zero_damaged_pagesto 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.
|ISBN 0954612043||PostgreSQL Reference Manual - Volume 3 - Server Administration Guide||See the print edition|