18.17. Параметры для разработчиков
Следующие параметры предназначены для работы над исходным кодом PostgreSQL, а в некоторых случаях они могут помочь восстановить сильно повреждённые базы данных. Для использования их в производственной среде не должно быть причин, поэтому они исключены из примера файла postgresql.conf. Заметьте, что для работы с многими из этих параметров требуются специальные флаги компиляции.
allow_system_table_mods(boolean)Разрешает модификацию структуры системных таблиц. Этот параметр используется командой
initdb. Задать этот параметр можно только при запуске сервера.ignore_system_indexes(boolean)Отключает использование индексов при чтении системных таблиц (при этом индексы всё же будут изменяться при записи в эти таблицы). Это полезно для восстановления работоспособности при повреждённых системных индексах. Этот параметр нельзя изменить после запуска сеанса.
post_auth_delay(integer)При ненулевом значении этот параметр задаёт задержку (в секундах) при запуске нового серверного процесса после выполнения процедуры аутентификации. Он предназначен для того, чтобы разработчики имели возможность подключить отладчик к серверному процессу. Этот параметр нельзя изменить после начала сеанса.
pre_auth_delay(integer)При ненулевом значении этот параметр задаёт задержку (в секундах), добавляемую сразу после порождения нового серверного процесса, до выполнения процедуры аутентификации. Он предназначен для того, чтобы разработчики имели возможность подключить отладчик к серверному процессу при решении проблем с аутентификацией. Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.trace_notify(boolean)Включает вывод очень подробной отладочной информации при выполнении команд
LISTENиNOTIFY. Чтобы эти сообщения передавались клиенту или в журнал сервера, параметр client_min_messages или log_min_messages, соответственно, должен иметь значениеDEBUG1или ниже.trace_recovery_messages(enum)Включает вывод в журнал отладочных сообщений, связанных с восстановлением, которые иначе не выводятся. Этот параметр позволяет пользователю переопределить обычное значение log_min_messages, но только для специфических сообщений. Он предназначен для отладки режима горячего резерва. Допустимые значения:
DEBUG5,DEBUG4,DEBUG3,DEBUG2,DEBUG1иLOG. Значение по умолчанию,LOG, никак не влияет на запись этих сообщений в журнал. С другими значениями отладочные сообщения, связанные с восстановлением, имеющие заданный приоритет или выше, выводятся, как если бы они имели приоритетLOG; при стандартных значенияхlog_min_messagesэто означает, что они будут фиксироваться в журнале сервера. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.trace_sort(boolean)Включает вывод информации об использовании ресурсов во время операций сортировки. Этот параметр доступен, только если при сборке PostgreSQL был определён макрос
TRACE_SORT. (По умолчанию макросTRACE_SORTопределён.)trace_locks(boolean)Включает вывод подробных сведений о блокировках. В эти сведения входит вид операции блокировки, тип блокировки и уникальный идентификатор объекта, который блокируется или разблокируется. Кроме того, в их составе выводятся битовые маски для типов блокировок, уже полученных для данного объекта, и для типов блокировок, ожидающих его освобождения. В дополнение к этому выводится количество полученных и ожидающих блокировок для каждого типа блокировок, а также их общее количество. Ниже показан пример вывода в журнал:
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)Подробнее о структуре выводимой информации можно узнать в
src/include/storage/lock.h.Этот параметр доступен, только если при компиляции PostgreSQL был определён макрос
LOCK_DEBUG.trace_lwlocks(boolean)Включает вывод информации об использовании легковесных блокировок. Такие блокировки предназначены в основном для взаимоисключающего доступа к общим структурам данных в памяти.
Этот параметр доступен, только если при компиляции PostgreSQL был определён макрос
LOCK_DEBUG.trace_userlocks(boolean)Включает вывод информации об использовании пользовательских блокировок. Она выводится в том же формате, что и с
trace_locks, но по рекомендательным блокировкам.Этот параметр доступен, только если при компиляции PostgreSQL был определён макрос
LOCK_DEBUG.trace_lock_oidmin(integer)Если этот параметр установлен, при трассировке блокировок не будут отслеживаться таблицы с OID меньше заданного (это используется для исключения из трассировки системных таблиц).
Этот параметр доступен, только если при компиляции PostgreSQL был определён макрос
LOCK_DEBUG.trace_lock_table(integer)Безусловно трассировать блокировки для таблицы с заданным OID.
Этот параметр доступен, только если при компиляции PostgreSQL был определён макрос
LOCK_DEBUG.debug_deadlocks(boolean)Включает вывод информации обо всех текущих блокировках при тайм-ауте взаимоблокировки.
Этот параметр доступен, только если при компиляции PostgreSQL был определён макрос
LOCK_DEBUG.log_btree_build_stats(boolean)Включает вывод статистики использования системных ресурсов (памяти и процессора) при различных операциях с B-деревом.
Этот параметр доступен, только если при компиляции PostgreSQL был определён макрос
BTREE_BUILD_STATS.wal_debug(boolean)Включает вывод отладочной информации, связанной с WAL. Этот параметр доступен, только если при компиляции PostgreSQL был определён макрос
WAL_DEBUG.ignore_checksum_failure(boolean)Этот параметр действует, только если включён data checksums.
При обнаружении ошибок контрольных сумм при чтении PostgreSQL обычно сообщает об ошибке и прерывает текущую транзакцию. Если параметр
ignore_checksum_failureвключён, система игнорирует проблему (но всё же предупреждает о ней) и продолжает обработку. Это поведение может привести к краху, распространению или сокрытию повреждения данных и другим серьёзными проблемам. Однако, включив его, вы можете обойти ошибку и получить неповреждённые данные, которые могут находиться в таблице, если цел заголовок блока. Если же повреждён заголовок, будет выдана ошибка, даже когда этот параметр включён. По умолчанию этот параметр отключён (имеет значениеoff) и изменить его состояние может только суперпользователь.zero_damaged_pages(boolean)При выявлении повреждённого заголовка страницы PostgreSQL обычно сообщает об ошибке и прерывает текущую транзакцию. Если параметр
zero_damaged_pagesвключён, вместо этого система выдаёт предупреждение, обнуляет повреждённую страницу в памяти и продолжает обработку. Это поведение разрушает данные, а именно все строки в повреждённой странице. Однако, включив его, вы можете обойти ошибку и получить строки из неповреждённых страниц, которые могут находиться в таблице. Это бывает полезно для восстановления данных, испорченных в результате аппаратной или программной ошибки. Обычно включать его следует только тогда, когда не осталось никакой другой надежды на восстановление данных в повреждённых страницах таблицы. Обнулённые страницы не сохраняются на диск, поэтому прежде чем выключать этот параметр, рекомендуется пересоздать проблемные таблицы или индексы. По умолчанию этот параметр отключён (имеет значениеoff) и изменить его состояние может только суперпользователь.
18.17. Developer Options
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.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.conffile or on the server command line.trace_notify(boolean)Generates a great amount of debugging output for the
LISTENandNOTIFYcommands. client_min_messages or log_min_messages must beDEBUG1or 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, andLOG. 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 hadLOGpriority; for common settings oflog_min_messagesthis results in unconditionally sending them to the server log. This parameter can only be set in thepostgresql.conffile 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_SORTmacro was defined when PostgreSQL was compiled. (However,TRACE_SORTis 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_DEBUGmacro 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_DEBUGmacro 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_DEBUGmacro 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_DEBUGmacro 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_DEBUGmacro 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_DEBUGmacro 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_STATSmacro was defined when PostgreSQL was compiled.wal_debug(boolean)If on, emit WAL-related debugging output. This parameter is only available if the
WAL_DEBUGmacro 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_failureto 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 isoff, 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_pagesto 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 isoff, and it can only be changed by a superuser.