19.19. Параметры для разработчиков #
Следующие параметры предназначены для тестирования в процессе разработки, и их никогда не следует применять в производственной среде. (Однако в некоторых случаях они могут помочь восстановить сильно повреждённые базы данных.) По этим причинам они отсутствуют в примере файла postgresql.conf
. Заметьте, что для использования многих из этих параметров требуются специальные флаги компиляции.
allow_in_place_tablespaces
(boolean
) #Позволяет создавать табличные пространства как каталоги в
pg_tblspc
, когда в качестве пути расположения в командеCREATE TABLESPACE
задана пустая строка. Эта возможность предназначена для тестирования сценариев репликации, когда ведущий и ведомый серверы работают на одном компьютере. Существование каталогов в этом месте может оказаться неожиданным для средств резервного копирования, которые рассчитывают найти там только символические ссылки. Изменять этот параметр могут только суперпользователи и пользователи с соответствующим правомSET
.allow_system_table_mods
(boolean
) #Разрешает модификации структуры системных таблиц, а также некоторые другие потенциально опасные операции с системными таблицами. Если данный параметр отключён, эти действия не разрешены даже суперпользователям. Непродуманное использование этого параметра чревато неисправимыми повреждениями данных и разрушением всей СУБД. Изменить этот параметр могут только суперпользователи и пользователи с соответствующим правом
SET
.backtrace_functions
(string
) #В этом параметре задаётся разделённый запятыми список имён функций C. В случае возникновения ошибки в функции, имя которой присутствует в этом списке, в журнал сервера помимо сообщения об ошибке будет выводиться трассировка стека. Это может быть полезно для отладки в определённых местах исходного кода.
Поддержка трассировки стека имеется не на всех платформах, а информационная ценность трассировки зависит от параметров компиляции.
Только суперпользователи и пользователи с соответствующим правом
SET
могут изменить этот параметр.debug_discard_caches
(integer
) #Если установлено значение
1
, каждая запись кеша системного каталога становится недействительной при первой же возможности, независимо от того, произошло ли на самом деле что-то, что могло бы сделать её недействительной. В результате кеширование системных каталогов фактически отключается, поэтому сервер будет работать очень медленно. При увеличении значения этого параметра аннулирование кеша производится рекурсивно, что приводит к ещё большему замедлению и полезно только для тестирование собственно логики кеширования. Значение по умолчанию —0
— включает обычное поведение кеширования каталога.Этот параметр может быть очень полезен при выявлении трудновоспроизводимых ошибок, связанных с одновременными изменениями в каталоге, но редко бывает нужен в других случаях.
Этот параметр поддерживается, если при компиляции был определён макрос
DISCARD_CACHES_ENABLED
(он определяется автоматически при выполнении configure с ключом--enable-cassert
). В обычных сборках его значение всегда будет0
; при попытке изменить это значение возникнет ошибка.debug_io_direct
(string
) #Обращается к ядру для минимизации кеширования данных отношений и файлов WAL, используя
O_DIRECT
(большинство Unix-подобных систем),F_NOCACHE
(macOS) илиFILE_FLAG_NO_BUFFERING
(Windows).Значение может представлять собой пустую строку (по умолчанию), чтобы отключить использование прямого ввода/вывода, или список операций, разделённых запятыми, в которых может использоваться прямой ввод/вывод. Варианты операций:
data
для основных файлов данных,wal
для файлов WAL иwal_init
для файлов WAL при первоначальном размещении.Некоторые операционные и файловые системы не поддерживают прямой ввод/вывод, так что нестандартные значения параметра могут не приниматься при запуске или вызывать ошибки.
В настоящее время эта функциональность снижает производительность и предназначена только для тестирования.
debug_parallel_query
(enum
) #Позволяет распараллеливать запрос в целях тестирования, даже когда от этого не ожидается никакого выигрыша в скорости. Допустимые значения параметра
debug_parallel_query
—off
(использовать параллельный режим только когда ожидается увеличение производительности),on
(принудительно распараллеливать все запросы, для которых это безопасно) иregress
(какon
, но с дополнительными изменениями поведения, описанными ниже).Говоря точнее, со значением
on
узелGather
добавляется в вершину любого плана запроса, для которого допускается распараллеливание, так что запрос выполняется внутри параллельного исполнителя. Даже когда параллельный исполнитель недоступен или не может быть использован, такие операции, как запуск подтранзакции, которые не должны выполняться в контексте параллельного запроса, не будут выполняться в этом режиме, если только планировщик не решит, что это приведёт к ошибке запроса. Если при включении этого параметра возникают ошибки или выдаются неожиданные результаты, вероятно, некоторые функции, задействованные в этом запросе, нужно пометить какPARALLEL UNSAFE
(или, возможно,PARALLEL RESTRICTED
).Значение
regress
действует так же, как и значениеon
, с некоторыми дополнительными особенностями, предназначенными для облегчения автоматического регрессионного тестирования. Обычно сообщения от параллельных исполнителей включают строку контекста, отмечающую это, но значениеregress
подавляет эту строку, так что вывод не отличается от выполнения в не параллельном режиме. Кроме того, узлыGather
, добавляемые в планы с этим значением параметра, скрываются в выводеEXPLAIN
, чтобы вывод соответствовал тому, что будет получен при отключении этого параметра (со значениемoff
).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_sort
(boolean
) #Включает вывод информации об использовании ресурсов во время операций сортировки. Этот параметр доступен, только если при сборке Postgres Pro был определён макрос
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)
Этот параметр доступен, только если при компиляции Postgres Pro был определён макрос
LOCK_DEBUG
.trace_lwlocks
(boolean
) #Включает вывод информации об использовании легковесных блокировок. Такие блокировки предназначены в основном для взаимоисключающего доступа к общим структурам данных в памяти.
Этот параметр доступен, только если при компиляции Postgres Pro был определён макрос
LOCK_DEBUG
.trace_userlocks
(boolean
) #Включает вывод информации об использовании пользовательских блокировок. Она выводится в том же формате, что и с
trace_locks
, но по рекомендательным блокировкам.Этот параметр доступен, только если при компиляции Postgres Pro был определён макрос
LOCK_DEBUG
.trace_lock_oidmin
(integer
) #Если этот параметр установлен, при трассировке блокировок не будут отслеживаться таблицы с OID меньше заданного (это используется для исключения из трассировки системных таблиц).
Этот параметр доступен, только если при компиляции Postgres Pro был определён макрос
LOCK_DEBUG
.trace_lock_table
(integer
) #Безусловно трассировать блокировки для таблицы с заданным OID.
Этот параметр доступен, только если при компиляции Postgres Pro был определён макрос
LOCK_DEBUG
.debug_deadlocks
(boolean
) #Включает вывод информации обо всех текущих блокировках при тайм-ауте взаимоблокировки.
Этот параметр доступен, только если при компиляции Postgres Pro был определён макрос
LOCK_DEBUG
.log_btree_build_stats
(boolean
) #Включает вывод статистики использования системных ресурсов (памяти и процессора) при различных операциях с B-деревом.
Этот параметр доступен, только если при компиляции Postgres Pro был определён макрос
BTREE_BUILD_STATS
.wal_consistency_checking
(string
) #Этот параметр предназначен для проверки ошибок в процедурах воспроизведения WAL. Когда он включён, в записи WAL добавляются полные образы страниц всех изменяемых буферов, Когда запись впоследствии воспроизводится, система сначала применяет эту запись, а затем проверяет, соответствуют ли буферы, изменённые записью, сохранённым образам. В определённых случаях (например, во вспомогательных битах) небольшие изменения допускаются и будут игнорироваться. Если выявляются неожиданные различия, это считается критической ошибкой и восстановление прерывается.
По умолчанию значение этого параметра — пустая строка, так что эта функциональность отключена. Его значением может быть
all
(будут проверяться все записи) или список имён менеджеров ресурсов через запятую (будут проверяться записи, выдаваемые этими менеджерами). В настоящее время поддерживаются менеджерыheap
,heap2
,btree
,hash
,gin
,gist
,sequence
,spgist
,brin
иgeneric
. В расширениях могут определяться и другие менеджеры ресурсов. Изменять этот параметр могут только суперпользователи и пользователи с соответствующим правомSET
.wal_debug
(boolean
) #Включает вывод отладочной информации, связанной с WAL. Этот параметр доступен, только если при компиляции Postgres Pro был определён макрос
WAL_DEBUG
.ignore_checksum_failure
(boolean
) #Этот параметр действует, только если включён Контрольные суммы данных.
При обнаружении ошибок контрольных сумм при чтении Postgres Pro обычно сообщает об ошибке и прерывает текущую транзакцию. Если параметр
ignore_checksum_failure
включён, система игнорирует проблему (но всё же предупреждает о ней) и продолжает обработку. Это поведение может привести к краху, распространению или сокрытию повреждения данных и другим серьёзными проблемам. Однако включив его, вы можете обойти ошибку и получить неповреждённые данные, которые могут находиться в таблице, если цел заголовок блока. Если же повреждён заголовок, будет выдана ошибка, даже когда этот параметр включён. По умолчанию этот параметр отключён (имеет значениеoff
). Только суперпользователи и пользователи с соответствующим правомSET
могут изменить этот параметр.zero_damaged_pages
(boolean
) #При выявлении повреждённого заголовка страницы Postgres Pro обычно сообщает об ошибке и прерывает текущую транзакцию. Если параметр
zero_damaged_pages
включён, вместо этого система выдаёт предупреждение, обнуляет повреждённую страницу в памяти и продолжает обработку. Это поведение разрушает данные, а именно все строки в повреждённой странице. Однако включив его, вы можете обойти ошибку и получить строки из неповреждённых страниц, которые могут находиться в таблице. Это бывает полезно для восстановления данных, испорченных в результате аппаратной или программной ошибки. Обычно включать его следует только тогда, когда не осталось никакой другой надежды на восстановление данных в повреждённых страницах таблицы. Обнулённые страницы не сохраняются на диск, поэтому прежде чем выключать этот параметр, рекомендуется пересоздать проблемные таблицы или индексы. По умолчанию этот параметр отключён (имеет значениеoff
). Только суперпользователи и пользователи с соответствующим правомSET
могут изменить этот параметр.ignore_invalid_pages
(boolean
) #Когда этот параметр имеет значение
off
(по умолчанию), обнаружение в WAL записей, ссылающихся на некорректные страницы, в процессе восстановления приводит к остановке Postgres Pro с ошибкой критического уровня и, как следствие, к прерыванию восстановления. Когда параметрignore_invalid_pages
включён (on
), система игнорирует подобные недействительные ссылки в записях WAL (но всё же выдаёт предупреждения) и продолжает восстановление. Это поведение может привести к краху, потере данных, распространению или сокрытию повреждения данных и другим серьёзными проблемам. Однако включив этот параметр, вы можете обойти критическую ошибку и закончить восстановление, чтобы сервер всё же запустился. Задать этот параметр можно только при запуске сервера. Действует он только при восстановлении или в режиме ведомого.jit_debugging_support
(boolean
) #При наличии требуемой функциональности LLVM регистрировать генерируемые функции в GDB. Это позволяет упростить отладку. Значение по умолчанию —
off
(выкл.). Изменить этот параметр можно только при запуске сервера.jit_dump_bitcode
(boolean
) #Записывать сгенерированный LLVM IR-код в файловую систему, в каталог data_directory. Это полезно только для работы с внутренним механизмом JIT. Значение по умолчанию —
off
(выкл.). Только суперпользователи и пользователи с соответствующим правомSET
могут изменить этот параметр.jit_expressions
(boolean
) #Определяет, будут ли JIT-компилироваться выражения, когда JIT-компиляция включена (см. Раздел 30.2). Значение по умолчанию —
on
(вкл.).jit_profiling_support
(boolean
) #При наличии требуемой функциональности LLVM выдавать данные, необходимые для профилирования с помощью perf функций, которые генерирует JIT. Выходные файлы записываются в каталог
~/.debug/jit/
; удалять их при желании должен сам пользователь. Значение по умолчанию —off
(выкл.). Задать этот параметр можно только при запуске сервера.jit_tuple_deforming
(boolean
) #Определяет, будет ли JIT-компилироваться преобразование кортежей, когда JIT-компиляция включена (см. Раздел 30.2). Значение по умолчанию —
on
(вкл.).remove_temp_files_after_crash
(boolean
) #Если этот параметр включён (состояние по умолчанию), Postgres Pro автоматически удаляет временные файлы после сбоя сервера. Если он выключен, файлы будут сохранены и могут использоваться, например, для отладки. Однако повторяющиеся сбои могут привести к накоплению бесполезных файлов. Этот параметр можно задать только в
postgresql.conf
или в командной строке при запуске сервера.send_abort_for_crash
(boolean
) #По умолчанию после сбоя сервера управляющий процесс postmaster останавливает оставшиеся дочерние процессы, отправляя им сигналы SIGQUIT, что позволяет им завершить работу более или менее корректно. Если для этого параметра установлено значение
on
, вместо SIGQUIT отправляется SIGABRT. Обычно это приводит к созданию файла дампа памяти для каждого такого дочернего процесса. Это может быть удобно для исследования состояний других процессов после сбоя. Но такие файлы также могут занимать много места на диске в случае повторяющихся сбоев, поэтому не включайте параметр в системах без тщательного мониторинга. Имейте в виду, что автоматическое удаление дампов памяти не поддерживается. Этот параметр можно задать только в файлеpostgresql.conf
или в командной строке при запуске сервера.send_abort_for_kill
(boolean
) #По умолчанию после попытки остановить дочерний процесс, используя сигнал SIGQUIT, управляющий процесс postmaster ждёт пять секунд, а затем отправляет SIGKILL для немедленного завершения. Если для этого параметра установлено значение
on
, вместо SIGKILL отправляется SIGABRT. Обычно это приводит к созданию файла дампа памяти для каждого такого дочернего процесса. Это может быть удобно для исследования состояний «зависших» дочерних процессов. Но такие файлы также могут занимать много места на диске в случае повторяющихся сбоев, поэтому не включайте параметр в системах без тщательного мониторинга. Имейте в виду, что автоматическая очистка файлов дампа не поддерживается. Этот параметр можно задать только в файлеpostgresql.conf
или в командной строке при запуске сервера.debug_logical_replication_streaming
(enum
) #Допустимые значения:
buffered
иimmediate
. По умолчанию используетсяbuffered
. Этот параметр предназначен для тестирования логического декодирования и репликации больших транзакций. Параметрdebug_logical_replication_streaming
на публикующем сервере и на подписчике работает по-разному:На стороне публикующего сервера
debug_logical_replication_streaming
позволяет выполнять потоковую передачу или сериализацию изменений сразу же при логическом декодировании. Если установлено значениеimmediate
, каждое изменение передаётся в потоковом режиме, если подписка была создана с параметромstreaming
, в противном случае изменения сериализуются. Если установлено значениеbuffered
, при декодировании изменения передаются в потоке или сериализуются при достижении значенияlogical_decoding_work_mem
.На стороне подписчика, если для параметра
streaming
задано значениеparallel
, можно использоватьdebug_logical_replication_streaming
, чтобы указать ведущему процессу применения изменений отправлять изменения в очередь общей памяти или для сериализации всех изменений в файле. Если задано значениеbuffered
, ведущий процесс отправляет изменения параллельным рабочим процессам применения изменений через очередь общей памяти. Если установлено значениеimmediate
, ведущий процесс сериализует все изменения в файлы и уведомляет параллельные рабочие процессы применения изменений о необходимости их чтения и применения в конце транзакции.