| Postgres-XC 1.0.1 Documentation | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 17. Coordinator and Datanode Configuration | Fast Forward | Next |
Note: The following description applies both to Postgres-XC and PostgreSQL if not described explicitly.
The following parameters are intended for work on the Postgres-XC 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.
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_CHECKING must be defined when Postgres-XC is built (accomplished by the configure option --enable-cassert). Note that debug_assertions defaults to on if Postgres-XC 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 developers 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 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.
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.
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.
If on, emit information about resource usage during sort operations. This parameter is only available if the TRACE_SORT macro was defined when Postgres-XC was compiled. (However, TRACE_SORT is currently defined by default.)
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 Postgres-XC was compiled.
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 Postgres-XC was compiled.
If on, emit information about user lock usage. Output is the same as for trace_locks, only for user locks.
User locks were removed as of PostgreSQL version 8.2. This option currently has no effect.
This parameter is only available if the LOCK_DEBUG macro was defined when Postgres-XC was compiled.
If set, do not trace locks for tables below this OID. (use to avoid output on system tables)
This parameter is only available if the LOCK_DEBUG macro was defined when Postgres-XC was compiled.
Unconditionally trace locks on this table (OID).
This parameter is only available if the LOCK_DEBUG macro was defined when Postgres-XC was compiled.
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 Postgres-XC was compiled.
Note: The following description applies only to Postgres-XC
Postgres-XC does not detect global deadlocks where multiple node (Coordinators and/or Datanodes) are involved.
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 Postgres-XC was compiled.
If on, emit WAL-related debugging output. This parameter is only available if the WAL_DEBUG macro was defined when Postgres-XC was compiled.
Detection of a damaged page header normally causes Postgres-XC 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.