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

Следующие параметры предназначены для тестирования в процессе разработки, и их никогда не следует применять в производственной среде. (Однако в некоторых случаях они могут помочь восстановить сильно повреждённые базы данных.) По этим причинам они отсутствуют в примере файла 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_queryoff (использовать параллельный режим только когда ожидается увеличение производительности), 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_recovery_messages (enum) #

Включает вывод в журнал отладочных сообщений, связанных с восстановлением, которые иначе не выводятся. Этот параметр позволяет пользователю переопределить обычное значение log_min_messages, но только для специфических сообщений. Он предназначен для отладки режима горячего резерва. Допустимые значения: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1 и LOG. Значение по умолчанию, LOG, никак не влияет на запись этих сообщений в журнал. С другими значениями отладочные сообщения, связанные с восстановлением, имеющие заданный приоритет или выше, выводятся, как если бы они имели приоритет LOG; при стандартных значениях log_min_messages это означает, что они будут фиксироваться в журнале сервера. Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера.

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 (выкл.). Изменить этот параметр могут только суперпользователи и пользователи с соответствующим правомSET при запуске сеанса. После запуска изменить его нельзя.

jit_dump_bitcode (boolean) #

Записывать сгенерированный LLVM IR-код в файловую систему, в каталог data_directory. Это полезно только для работы с внутренним механизмом JIT. Значение по умолчанию — off (выкл.). Только суперпользователи и пользователи с соответствующим правом SET могут изменить этот параметр.

jit_expressions (boolean) #

Определяет, будут ли JIT-компилироваться выражения, когда JIT-компиляция включена (см. Раздел 30.2). Значение по умолчанию — on (вкл.).

jit_profiling_support (boolean) #

При наличии требуемой функциональности LLVM выдавать данные, необходимые для профилирования функций, которые генерирует JIT, с помощью perf. Выходные файлы записываются в каталог ~/.debug/jit/; удалять их при желании должен сам пользователь. Значение по умолчанию — off (выкл.). Изменить этот параметр могут только суперпользователи и пользователи с соответствующим правомSET при запуске сеанса. После запуска изменить его нельзя.

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, ведущий процесс сериализует все изменения в файлы и уведомляет параллельные рабочие процессы применения изменений о необходимости их чтения и применения в конце транзакции.

18.18. Developer Options #

The following parameters are intended for developer testing, and should never be used on a production database. However, some of them can be used to assist with the recovery of severely damaged databases. 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_in_place_tablespaces (boolean) #

Allows tablespaces to be created as directories inside pg_tblspc, when an empty location string is provided to the CREATE TABLESPACE command. This is intended to allow testing replication scenarios where primary and standby servers are running on the same machine. Such directories are likely to confuse backup tools that expect to find only symbolic links in that location. Only superusers and users with the appropriate SET privilege can change this setting.

allow_system_table_mods (boolean) #

Allows modification of the structure of system tables as well as certain other risky actions on system tables. This is otherwise not allowed even for superusers. Ill-advised use of this setting can cause irretrievable data loss or seriously corrupt the database system. Only superusers and users with the appropriate SET privilege can change this setting.

backtrace_functions (string) #

This parameter contains a comma-separated list of C function names. If an error is raised and the name of the internal C function where the error happens matches a value in the list, then a backtrace is written to the server log together with the error message. This can be used to debug specific areas of the source code.

Backtrace support is not available on all platforms, and the quality of the backtraces depends on compilation options.

Only superusers and users with the appropriate SET privilege can change this setting.

debug_discard_caches (integer) #

When set to 1, each system catalog cache entry is invalidated at the first possible opportunity, whether or not anything that would render it invalid really occurred. Caching of system catalogs is effectively disabled as a result, so the server will run extremely slowly. Higher values run the cache invalidation recursively, which is even slower and only useful for testing the caching logic itself. The default value of 0 selects normal catalog caching behavior.

This parameter can be very helpful when trying to trigger hard-to-reproduce bugs involving concurrent catalog changes, but it is otherwise rarely needed.

This parameter is supported when DISCARD_CACHES_ENABLED was defined at compile time (which happens automatically when using the configure option --enable-cassert). In production builds, its value will always be 0 and attempts to set it to another value will raise an error.

debug_io_direct (string) #

Ask the kernel to minimize caching effects for relation data and WAL files using O_DIRECT (most Unix-like systems), F_NOCACHE (macOS) or FILE_FLAG_NO_BUFFERING (Windows).

May be set to an empty string (the default) to disable use of direct I/O, or a comma-separated list of operations that should use direct I/O. The valid options are data for main data files, wal for WAL files, and wal_init for WAL files when being initially allocated. This parameter can only be set at server start.

Some operating systems and file systems do not support direct I/O, so non-default settings may be rejected at startup or cause errors.

Currently this feature reduces performance, and is intended for developer testing only.

debug_parallel_query (enum) #

Allows the use of parallel queries for testing purposes even in cases where no performance benefit is expected. The allowed values of debug_parallel_query are off (use parallel mode only when it is expected to improve performance), on (force parallel query for all queries for which it is thought to be safe), and regress (like on, but with additional behavior changes as explained below).

More specifically, setting this value to on will add a Gather node to the top of any query plan for which this appears to be safe, so that the query runs inside of a parallel worker. Even when a parallel worker is not available or cannot be used, operations such as starting a subtransaction that would be prohibited in a parallel query context will be prohibited unless the planner believes that this will cause the query to fail. If failures or unexpected results occur when this option is set, some functions used by the query may need to be marked PARALLEL UNSAFE (or, possibly, PARALLEL RESTRICTED).

Setting this value to regress has all of the same effects as setting it to on plus some additional effects that are intended to facilitate automated regression testing. Normally, messages from a parallel worker include a context line indicating that, but a setting of regress suppresses this line so that the output is the same as in non-parallel execution. Also, the Gather nodes added to plans by this setting are hidden in EXPLAIN output so that the output matches what would be obtained if this setting were turned off.

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

The amount of time to delay 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. If this value is specified without units, it is taken as seconds. A value of zero (the default) disables the delay. This parameter cannot be changed after session start.

pre_auth_delay (integer) #

The amount of time to delay 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. If this value is specified without units, it is taken as seconds. A value of zero (the default) disables the delay. This parameter can only be set in the postgresql.conf file or on the server command line.

trace_notify (boolean) #

Generates a great amount of debugging output for the LISTEN and NOTIFY commands. client_min_messages or log_min_messages must be DEBUG1 or 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, and LOG. 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 had LOG priority; for common settings of log_min_messages this results in unconditionally sending them to the server log. This parameter can only be set in the postgresql.conf file 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_SORT macro was defined when Postgres Pro was compiled. (However, TRACE_SORT is 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)

This parameter is only available if the LOCK_DEBUG macro was defined when Postgres Pro 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_DEBUG macro was defined when Postgres Pro 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_DEBUG macro was defined when Postgres Pro 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_DEBUG macro was defined when Postgres Pro was compiled.

trace_lock_table (integer) #

Unconditionally trace locks on this table (OID).

This parameter is only available if the LOCK_DEBUG macro was defined when Postgres Pro 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_DEBUG macro was defined when Postgres Pro 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_STATS macro was defined when Postgres Pro was compiled.

wal_consistency_checking (string) #

This parameter is intended to be used to check for bugs in the WAL redo routines. When enabled, full-page images of any buffers modified in conjunction with the WAL record are added to the record. If the record is subsequently replayed, the system will first apply each record and then test whether the buffers modified by the record match the stored images. In certain cases (such as hint bits), minor variations are acceptable, and will be ignored. Any unexpected differences will result in a fatal error, terminating recovery.

The default value of this setting is the empty string, which disables the feature. It can be set to all to check all records, or to a comma-separated list of resource managers to check only records originating from those resource managers. Currently, the supported resource managers are heap, heap2, btree, hash, gin, gist, sequence, spgist, brin, and generic. Extensions may define additional resource managers. Only superusers and users with the appropriate SET privilege can change this setting.

wal_debug (boolean) #

If on, emit WAL-related debugging output. This parameter is only available if the WAL_DEBUG macro was defined when Postgres Pro was compiled.

ignore_checksum_failure (boolean) #

Only has effect if data checksums are enabled.

Detection of a checksum failure during a read normally causes Postgres Pro to report an error, aborting the current transaction. Setting ignore_checksum_failure to 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 is off. Only superusers and users with the appropriate SET privilege can change this setting.

zero_damaged_pages (boolean) #

Detection of a damaged page header normally causes Postgres Pro to report an error, aborting the current transaction. Setting zero_damaged_pages to 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 is off. Only superusers and users with the appropriate SET privilege can change this setting.

ignore_invalid_pages (boolean) #

If set to off (the default), detection of WAL records having references to invalid pages during recovery causes Postgres Pro to raise a PANIC-level error, aborting the recovery. Setting ignore_invalid_pages to on causes the system to ignore invalid page references in WAL records (but still report a warning), and continue the recovery. This behavior may cause crashes, data loss, propagate or hide corruption, or other serious problems. However, it may allow you to get past the PANIC-level error, to finish the recovery, and to cause the server to start up. The parameter can only be set at server start. It only has effect during recovery or in standby mode.

jit_debugging_support (boolean) #

If LLVM has the required functionality, register generated functions with GDB. This makes debugging easier. The default setting is off. Only superusers and users with the appropriate SET privilege can change this parameter at session start, and it cannot be changed at all within a session.

jit_dump_bitcode (boolean) #

Writes the generated LLVM IR out to the file system, inside data_directory. This is only useful for working on the internals of the JIT implementation. The default setting is off. Only superusers and users with the appropriate SET privilege can change this setting.

jit_expressions (boolean) #

Determines whether expressions are JIT compiled, when JIT compilation is activated (see Section 30.2). The default is on.

jit_profiling_support (boolean) #

If LLVM has the required functionality, emit the data needed to allow perf to profile functions generated by JIT. This writes out files to ~/.debug/jit/; the user is responsible for performing cleanup when desired. The default setting is off. Only superusers and users with the appropriate SET privilege can change this parameter at session start, and it cannot be changed at all within a session.

jit_tuple_deforming (boolean) #

Determines whether tuple deforming is JIT compiled, when JIT compilation is activated (see Section 30.2). The default is on.

remove_temp_files_after_crash (boolean) #

When set to on, which is the default, Postgres Pro will automatically remove temporary files after a backend crash. If disabled, the files will be retained and may be used for debugging, for example. Repeated crashes may however result in accumulation of useless files. This parameter can only be set in the postgresql.conf file or on the server command line.

send_abort_for_crash (boolean) #

By default, after a backend crash the postmaster will stop remaining child processes by sending them SIGQUIT signals, which permits them to exit more-or-less gracefully. When this option is set to on, SIGABRT is sent instead. That normally results in production of a core dump file for each such child process. This can be handy for investigating the states of other processes after a crash. It can also consume lots of disk space in the event of repeated crashes, so do not enable this on systems you are not monitoring carefully. Beware that no support exists for cleaning up the core file(s) automatically. This parameter can only be set in the postgresql.conf file or on the server command line.

send_abort_for_kill (boolean) #

By default, after attempting to stop a child process with SIGQUIT, the postmaster will wait five seconds and then send SIGKILL to force immediate termination. When this option is set to on, SIGABRT is sent instead of SIGKILL. That normally results in production of a core dump file for each such child process. This can be handy for investigating the states of stuck child processes. It can also consume lots of disk space in the event of repeated crashes, so do not enable this on systems you are not monitoring carefully. Beware that no support exists for cleaning up the core file(s) automatically. This parameter can only be set in the postgresql.conf file or on the server command line.

debug_logical_replication_streaming (enum) #

The allowed values are buffered and immediate. The default is buffered. This parameter is intended to be used to test logical decoding and replication of large transactions. The effect of debug_logical_replication_streaming is different for the publisher and subscriber:

On the publisher side, debug_logical_replication_streaming allows streaming or serializing changes immediately in logical decoding. When set to immediate, stream each change if the streaming option of CREATE SUBSCRIPTION is enabled, otherwise, serialize each change. When set to buffered, the decoding will stream or serialize changes when logical_decoding_work_mem is reached.

On the subscriber side, if the streaming option is set to parallel, debug_logical_replication_streaming can be used to direct the leader apply worker to send changes to the shared memory queue or to serialize all changes to the file. When set to buffered, the leader sends changes to parallel apply workers via a shared memory queue. When set to immediate, the leader serializes all changes to files and notifies the parallel apply workers to read and apply them at the end of the transaction.

FAQ