18.17. Опции разработчика#

18.17. Опции разработчика

18.17. Опции разработчика #

Следующие параметры предназначены для тестирования разработчиками и никогда не должны использоваться в производственной базе данных. Однако некоторые из них могут быть использованы для восстановления серьезно поврежденных баз данных. Поэтому они были исключены из примера файла postgresql.conf. Обратите внимание, что для работы многих из этих параметров требуются специальные флаги компиляции исходного кода.

allow_in_place_tablespaces (boolean) #

Позволяет создавать таблицы в виде каталогов внутри pg_tblspc, когда пустая строка указывается в качестве местоположения в команде CREATE TABLESPACE. Это предназначено для тестирования сценариев репликации, когда основной и резервный серверы работают на одной машине. Такие каталоги могут запутать инструменты резервного копирования, которые ожидают наличие только символических ссылок в этом месте. Изменять эту настройку могут только суперпользователи и пользователи с соответствующими привилегиями SET.

allow_system_table_mods (boolean) #

Позволяет изменять структуру системных таблиц, а также выполнять определенные другие рискованные действия с системными таблицами. В противном случае, даже для суперпользователей это не разрешено. Неразумное использование этой настройки может привести к потере данных или серьезному повреждению базы данных. Только суперпользователи и пользователи с соответствующим привилегией SET могут изменять эту настройку.

backtrace_functions (string) #

Этот параметр содержит список имен функций на языке C, разделенных запятыми. Если возникает ошибка и имя внутренней функции на языке C, где произошла ошибка, совпадает со значением из списка, то вместе с сообщением об ошибке в журнал сервера записывается трассировка стека. Это может использоваться для отладки конкретных областей исходного кода.

Поддержка трассировки стека не доступна на всех платформах, и качество трассировок зависит от параметров компиляции.

Только суперпользователи и пользователи с соответствующим привилегией SET могут изменять это настройку.

backtrace_on_internal_error (boolean) #

Если этот параметр включен и возникает ошибка с кодом ошибки XX000 (внутренняя ошибка; см. также Предметный указатель A), то трассировка стека записывается в журнал сервера вместе с сообщением об ошибке. Это можно использовать для отладки таких внутренних ошибок (которые обычно не должны происходить в рабочей среде). По умолчанию выключено.

Поддержка трассировки стека не доступна на всех платформах, и качество трассировок зависит от параметров компиляции.

Только суперпользователи и пользователи с соответствующим привилегией SET могут изменять это настройку.

debug_discard_caches (integer) #

Когда установлено значение 1, каждая запись кеша системного каталога инвалидируется при первой возможности, независимо от того, произошло ли что-то, что могло бы сделать ее недействительной. Кеширование системных каталогов фактически отключается, поэтому сервер будет работать крайне медленно. Более высокие значения запускают рекурсивную инвалидацию кеша, что еще медленнее и полезно только для тестирования логики кеширования. Значение по умолчанию 0 выбирает нормальное поведение кеширования каталогов.

Этот параметр может быть очень полезен при попытке вызвать трудно воспроизводимые ошибки, связанные с одновременными изменениями каталога, но в остальных случаях он редко нужен. См. файлы исходного кода inval.c и pg_config_manual.h для получения подробной информации.

Этот параметр поддерживается, когда 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, чтобы вывод соответствовал тому, что было бы получено, если бы эта настройка была отключена.

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) #

Если включено, выводить информацию о использовании ресурсов во время сортировки. Этот параметр доступен только если макрос TRACE_SORT был определен при компиляции Tantor BE. (Однако, 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.

Этот параметр доступен только если макрос LOCK_DEBUG был определен при компиляции Tantor BE.

trace_lwlocks (boolean) #

Если включено, выводить информацию о использовании легковесных блокировок. Легковесные блокировки предназначены в основном для обеспечения взаимного исключения доступа к общим структурам данных в общей памяти.

Этот параметр доступен только если макрос LOCK_DEBUG был определен при компиляции Tantor BE.

trace_userlocks (boolean) #

Если включено, выводится информация об использовании пользовательских блокировок. Вывод аналогичен для тега trace_locks, только для рекомендательных блокировок.

Этот параметр доступен только если макрос LOCK_DEBUG был определен при компиляции Tantor BE.

trace_lock_oidmin (integer) #

Если установлено, не отслеживать блокировки для таблиц ниже этого OID (используется для исключения вывода для системных таблиц).

Этот параметр доступен только если макрос LOCK_DEBUG был определен при компиляции Tantor BE.

trace_lock_table (integer) #

Безусловно отслеживать блокировки на этой таблице (OID).

Этот параметр доступен только если макрос LOCK_DEBUG был определен при компиляции Tantor BE.

debug_deadlocks (boolean) #

Если установлено, выводит информацию о всех текущих блокировках при возникновении тайм-аута дедлока.

Этот параметр доступен только если макрос LOCK_DEBUG был определен при компиляции Tantor BE.

log_btree_build_stats (boolean) #

Если установлено, регистрирует статистику использования системных ресурсов (памяти и ЦП) при различных операциях с B-деревьями.

Этот параметр доступен только если макрос BTREE_BUILD_STATS был определен при компиляции Tantor BE.

wal_consistency_checking (string) #

Этот параметр предназначен для проверки наличия ошибок в процедурах восстановления журнала транзакций (WAL). При включении этого параметра, полностраничные изображения любых буферов, измененных вместе с записью WAL, добавляются к записи. Если запись воспроизводится позже, система сначала применит каждую запись, а затем проверит, соответствуют ли буферы, измененные записью, сохраненным изображениям. В некоторых случаях (например, признаки подсказки), допустимы незначительные отклонения, которые будут проигнорированы. Любые неожиданные отличия приведут ккритической ошибке и прекращению восстановления.

Значение по умолчанию для этой настройки - пустая строка, что отключает функцию. Его можно установить на all, чтобы проверить все записи, или на список ресурсных менеджеров, разделенных запятыми, чтобы проверить только записи, происходящие из этих ресурсных менеджеров. В настоящее время поддерживаются следующие ресурсные менеджеры: heap, heap2, btree, hash, gin, gist, sequence, spgist, brin и generic. Расширения могут определять дополнительные ресурсные менеджеры. Изменить эту настройку могут только суперпользователи и пользователи с соответствующими привилегиями SET.

wal_debug (boolean) #

Если включено, выводить отладочную информацию, связанную с WAL. Этот параметр доступен только если макрос WAL_DEBUG был определен при компиляции Tantor BE.

ignore_checksum_failure (boolean) #

Имеет эффект только в том случае, если data checksums включены.

Обнаружение ошибки контрольной суммы во время чтения обычно приводит к ошибке и прерыванию текущей транзакции в Tantor BE. Установка параметра ignore_checksum_failure в значение on позволяет системе игнорировать ошибку (но все равно сообщать предупреждение) и продолжать обработку. Это поведение может привести к сбоям, распространению или скрытию повреждений или другим серьезным проблемам. Однако, это может позволить вам преодолеть ошибку и получить неиспорченные кортежи, которые могут все еще находиться в таблице, если заголовок блока все еще является целым. Если заголовок поврежден, будет сообщена ошибка, даже если этот параметр включен. Значение по умолчанию - off. Изменить этот параметр могут только суперпользователи и пользователи с соответствующими привилегиями SET.

zero_damaged_pages (boolean) #

Обнаружение поврежденного заголовка страницы обычно приводит к ошибке и прерыванию текущей транзакции в Tantor BE. Установка параметра zero_damaged_pages в значение on приводит к выводу предупреждения, обнулению поврежденной страницы в памяти и продолжению обработки. Такое поведение уничтожает данные, а именно все строки на поврежденной странице. Однако это позволяет пропустить ошибку и извлечь строки из неповрежденных страниц, которые могут быть в таблице. Это полезно для восстановления данных, если возникла коррупция из-за ошибки аппаратного или программного обеспечения. Обычно этот параметр не следует включать, пока не будет отказано от восстановления данных с поврежденных страниц таблицы. Обнуленные страницы не записываются на диск, поэтому рекомендуется перед отключением этого параметра повторно создать таблицу или индекс. Значение по умолчанию - off. Изменить этот параметр могут только суперпользователи и пользователи с соответствующими привилегиями SET.

ignore_invalid_pages (boolean) #

Если установлено значение off (по умолчанию), обнаружение WAL-записей, содержащих ссылки на недопустимые страницы во время восстановления, приводит к возникновению ошибки PANIC и прерыванию восстановления в Tantor BE. Установка параметра ignore_invalid_pages в значение on позволяет системе игнорировать недопустимые ссылки на страницы в WAL-записях (но все равно сообщать предупреждение) и продолжать восстановление. Это поведение может привести к сбоям, потере данных, распространению или скрытию повреждений или другим серьезным проблемам. Однако это может позволить вам преодолеть ошибку PANIC, завершить восстановление и запустить сервер. Параметр может быть установлен только при запуске сервера. Он имеет эффект только во время восстановления или в режиме ожидания.

jit_debugging_support (boolean) #

Если LLVM имеет необходимую функциональность, зарегистрируйте сгенерированные функции с помощью GDB. Это упрощает отладку. Значение по умолчанию - off. Этот параметр может быть установлен только при запуске сервера.

jit_dump_bitcode (boolean) #

Записывает сгенерированный IR LLVM в файловую систему, внутри 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) #

Когда установлено значение on, которое является значением по умолчанию, Tantor BE автоматически удаляет временные файлы после сбоя бэкенда. Если отключено, файлы будут сохранены и могут быть использованы для отладки, например. Однако, повторные сбои могут привести к накоплению бесполезных файлов. Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.

send_abort_for_crash (boolean) #

По умолчанию, после сбоя бэкенда постмастер остановит оставшиеся дочерние процессы, отправив им сигналы SIGQUIT, что позволяет им завершиться более-менее корректно. Когда эта опция установлена в on, вместо этого отправляется SIGABRT. Это обычно приводит к созданию файла дампа памяти для каждого такого дочернего процесса. Это может быть полезно для исследования состояния других процессов после сбоя. Это также может потреблять много дискового пространства в случае повторяющихся сбоев, поэтому не включайте эту опцию на системах, которые вы не контролируете внимательно. Учтите, что не существует поддержки для автоматической очистки файла(-ов) дампа памяти. Этот параметр можно установить только в файле postgresql.conf или в командной строке сервера.

send_abort_for_kill (boolean) #

По умолчанию, после попытки остановить дочерний процесс с SIGQUIT, постмастер будет ждать пять секунд, а затем отправит SIGKILL для принудительного немедленного завершения. Когда эта опция установлена в on, вместо SIGKILL отправляется SIGABRT. Это обычно приводит к созданию файла дампа памяти для каждого такого дочернего процесса. Это может быть полезно для исследования состояний зависших дочерних процессов. Это также может занять много дискового пространства в случае повторяющихся сбоев, поэтому не включайте эту опцию на системах, за которыми вы не следите внимательно. Учтите, что нет поддержки для автоматической очистки файла(-ов) дампа памяти. Этот параметр можно установить только в файле postgresql.conf или в командной строке сервера.

debug_logical_replication_streaming (enum) #

Допустимые значения: buffered и immediate. Значение по умолчанию: buffered. Этот параметр предназначен для тестирования логического декодирования и репликации больших транзакций. Эффект debug_logical_replication_streaming различается для издателя и подписчика:

На стороне издателя, debug_logical_replication_streaming позволяет немедленно передавать или сериализовать изменения в логическом декодировании. Когда установлено значение immediate, передавать каждое изменение, если streaming опция CREATE SUBSCRIPTION включена, в противном случае сериализовать каждое изменение. Когда установлено значение buffered, декодирование будет передавать или сериализовать изменения, когда достигнуто значение logical_decoding_work_mem.

На стороне подписчика, если опция streaming установлена в parallel, debug_logical_replication_streaming может быть использована для указания ведущему рабочему процессу применить изменения в очередь общей памяти или сериализовать все изменения в файл. Когда установлено в buffered, ведущий отправляет изменения параллельным рабочим процессам через очередь общей памяти. Когда установлено в immediate, ведущий сериализует все изменения в файлы и уведомляет параллельные рабочие процессы о необходимости прочитать и применить их в конце транзакции.