Параметры для разработчиков

примечание

Эта страница переведена при помощи нейросети GigaChat.

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

allow_in_place_tablespaces (boolean)

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

allow_system_table_mods (boolean)

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

backtrace_functions (string)

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

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

Только суперпользователи и пользователи с соответствующей 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, чтобы вывод соответствовал тому, что будет получен при отключении этого параметра (со значением 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)

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