19.17. Параметры для разработчиков
Следующие параметры предназначены для работы над исходным кодом PostgreSQL, а в некоторых случаях они могут помочь восстановить сильно повреждённые базы данных. Для использования их в производственной среде не должно быть причин, поэтому они исключены из примера файла postgresql.conf
. Заметьте, что для работы со многими из этих параметров требуются специальные флаги компиляции.
allow_in_place_tablespaces
(boolean
)Позволяет создавать табличные пространства как каталоги в
pg_tblspc
, когда в командеCREATE TABLESPACE
не указано расположение каталога. Это предназначено для тестирования сценариев репликации, когда ведущий и ведомый серверы работают на одном компьютере. Средства резервного копирования ожидают получить символические ссылки в этом месте, поэтому их работа может нарушиться. Изменять этот параметр могут только суперпользователи.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_consistency_checking
(string
)Этот параметр предназначен для проверки ошибок в процедурах воспроизведения WAL. Когда он включён, в записи WAL добавляются полные образы страниц всех изменяемых буферов, Когда запись впоследствии воспроизводится, система сначала применяет эту запись, а затем проверяет, соответствуют ли буферы, изменённые записью, сохранённым образам. В определённых случаях (например, во вспомогательных битах) небольшие изменения допускаются и будут игнорироваться. Если выявляются неожиданные различия, это считается критической ошибкой и восстановление прерывается.
По умолчанию значение этого параметра — пустая строка, так что эта функциональность отключена. Его значением может быть
all
(будут проверяться все записи) или список имён менеджеров ресурсов через запятую (будут проверяться записи, выдаваемые этими менеджерами). В настоящее время поддерживаются менеджерыheap
,heap2
,btree
,hash
,gin
,gist
,sequence
,spgist
,brin
иgeneric
. Изменять этот параметр могут только суперпользователи.wal_debug
(boolean
)Включает вывод отладочной информации, связанной с WAL. Этот параметр доступен, только если при компиляции PostgreSQL был определён макрос
WAL_DEBUG
.ignore_checksum_failure
(boolean
)Этот параметр действует, только если включён Контрольные суммы данных.
При обнаружении ошибок контрольных сумм при чтении PostgreSQL обычно сообщает об ошибке и прерывает текущую транзакцию. Если параметр
ignore_checksum_failure
включён, система игнорирует проблему (но всё же предупреждает о ней) и продолжает обработку. Это поведение может привести к краху, распространению или сокрытию повреждения данных и другим серьёзными проблемам. Однако включив его, вы можете обойти ошибку и получить неповреждённые данные, которые могут находиться в таблице, если цел заголовок блока. Если же повреждён заголовок, будет выдана ошибка, даже когда этот параметр включён. По умолчанию этот параметр отключён (имеет значениеoff
) и изменить его состояние может только суперпользователь.zero_damaged_pages
(boolean
)При выявлении повреждённого заголовка страницы PostgreSQL обычно сообщает об ошибке и прерывает текущую транзакцию. Если параметр
zero_damaged_pages
включён, вместо этого система выдаёт предупреждение, обнуляет повреждённую страницу в памяти и продолжает обработку. Это поведение разрушает данные, а именно все строки в повреждённой странице. Однако включив его, вы можете обойти ошибку и получить строки из неповреждённых страниц, которые могут находиться в таблице. Это бывает полезно для восстановления данных, испорченных в результате аппаратной или программной ошибки. Обычно включать его следует только тогда, когда не осталось никакой другой надежды на восстановление данных в повреждённых страницах таблицы. Обнулённые страницы не сохраняются на диск, поэтому прежде чем выключать этот параметр, рекомендуется пересоздать проблемные таблицы или индексы. По умолчанию этот параметр отключён (имеет значениеoff
) и изменить его состояние может только суперпользователь.jit_debugging_support
(boolean
)При наличии требуемой функциональности LLVM регистрировать генерируемые функции в GDB. Это позволяет упростить отладку. Значение по умолчанию —
off
(выкл.). Изменить этот параметр можно только при запуске сервера.jit_dump_bitcode
(boolean
)Записывать сгенерированный LLVM IR-код в файловую систему, в каталог data_directory. Это полезно только для работы с внутренним механизмом JIT. Значение по умолчанию —
off
(выкл.). Изменить этот параметр может только суперпользователь.jit_expressions
(boolean
)Определяет, будут ли JIT-компилироваться выражения, когда JIT-компиляция включена (см. Раздел 31.2). Значение по умолчанию —
on
(вкл.).jit_profiling_support
(boolean
)При наличии требуемой функциональности LLVM выдавать данные, необходимые для профилирования с помощью perf функций, которые генерирует JIT. Выходные файлы записываются в каталог
$HOME/.debug/jit/
; удалять их при желании должен сам пользователь. Значение по умолчанию —off
(выкл.). Задать этот параметр можно только при запуске сервера.jit_tuple_deforming
(boolean
)Определяет, будет ли JIT-компилироваться преобразование кортежей, когда JIT-компиляция включена (см. Раздел 31.2). Значение по умолчанию —
on
(вкл.).