Конфигурация сервера

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

Настройка параметров

Имена параметров и значения

Все имена параметров не чувствительны к регистру. Каждый параметр принимает значение одного из пяти типов: логическое, строковое, целое, с плавающей запятой или перечисляемое (enum). Тип определяет синтаксис для установки параметра:

  • Boolean: значения могут быть записаны как on, off, true, false, yes, no, 1, 0 (без учета регистра) или любым однозначным префиксом одного из них.

  • String: в общем случае заключайте значение в одинарные кавычки, удваивая любые одинарные кавычки внутри значения. Однако кавычки обычно можно опустить, если значение представляет собой простое число или идентификатор. (Значения, которые соответствуют ключевому слову SQL, требуют кавычек в некоторых контекстах).

  • Numeric (целое число и число с плавающей запятой): числовые параметры могут быть указаны в обычном формате целого числа и числа с плавающей запятой; дробные значения округляются до ближайшего целого числа, если параметр имеет целочисленный тип. Целочисленные параметры дополнительно принимают шестнадцатеричный ввод (начиная с 0x ) и восьмеричный ввод (начиная с 0), но эти форматы не могут иметь дроби. Не используйте тысячи разделителей. Кавычки не обязательны, за исключением шестнадцатеричного ввода.

  • Numeric with Unit: некоторые числовые параметры имеют неявную единицу, потому что они описывают количество памяти или времени. Единицей может быть байты, килобайты, блоки (обычно восемь килобайт), миллисекунды, секунды или минуты. Неукрашенное числовое значение для одной из этих настроек будет использовать единицу измерения по умолчанию, которую можно узнать из pg_settings.unit. Для удобства настройки могут быть заданы с явно заданной единицей измерения, например, ’120 ms’ для значения времени, и они будут преобразованы в любую фактическую единицу измерения параметра. Обратите внимание, что значение должно быть записано в виде строки (с кавычками), чтобы использовать эту функцию. Имя устройства чувствительно к регистру, и между числовым значением и единицей может быть пробел.

    • Допустимые единицы памяти: B (байты), kB (килобайты), MB (мегабайты), GB (гигабайты) и TB (терабайты). Множитель для блоков памяти равен 1024, а не 1000.

    • Допустимые единицы времени: us (микросекунды), ms (миллисекунды), s (секунды), min (минуты), h (часы) и d (дни).

  • Если дробное значение указано с единицей, оно будет округлено до кратного следующей меньшей единицы, если таковая имеется. Например, 30.1 GB будут преобразованы в 30822 MB не 32319628902 B Если параметр имеет целочисленный тип, окончательное округление до целого числа происходит после любого преобразования единиц.

  • Enumerated: параметры перечислимого типа записываются так же, как строковые параметры, но имеют ограниченный набор значений. Допустимые значения для такого параметра можно найти в pg_settings.enumvals. Перечисленные значения параметров не чувствительны к регистру.

Взаимодействие параметров через файл конфигурации

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

# This is a comment
log_connections = yes
log_destination = 'syslog'
search_path = '"$user", public'
shared_buffers = 128MB

В каждой строке указывается один параметр. Знак равенства между именем и значением необязателен. Пробелы незначительны (кроме как в значении параметра в кавычках), а пустые строки игнорируются. Хеш-метки (#) обозначают оставшуюся часть строки как комментарий. Значения параметров, которые не являются простыми идентификаторами или числами, должны быть заключены в одинарные кавычки. Чтобы вставить одинарную кавычку в значение параметра, напишите две кавычки (желательно) или обратную косую черту. Если файл содержит несколько записей для одного и того же параметра, все, кроме последнего, игнорируются.

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

Файл конфигурации перечитывается всякий раз, когда основной процесс сервера получает сигнал SIGHUP; этот сигнал легче всего отправить, запустив qhb_ctl reload из командной строки или вызвав функцию SQL pg_reload_conf(). Процесс основного сервера также передает этот сигнал всем запущенным в данный момент процессам сервера, так что существующие сеансы также принимают новые значения (это произойдет после того, как они выполнят любую выполняемую в настоящее время клиентскую команду). Кроме того, вы можете отправить сигнал непосредственно на один серверный процесс. Некоторые параметры могут быть установлены только при запуске сервера; любые изменения их записей в файле конфигурации будут игнорироваться до перезапуска сервера. Неверные настройки параметров в файле конфигурации также игнорируются (но регистрируются) во время обработки SIGHUP.

В дополнение к qhb.conf каталог данных QHB содержит файл qhb.auto.conf, который имеет тот же формат, что и qhb.conf но предназначен для редактирования автоматически, а не вручную. Этот файл содержит настройки, предоставленные командой ALTER SYSTEM. Этот файл читается всякий раз, когда есть qhb.conf, и его настройки действуют аналогичным образом. Настройки в qhb.auto.conf переопределяют настройки в qhb.conf.

Внешние инструменты также могут изменять qhb.auto.conf. Не рекомендуется делать это во время работы сервера, поскольку одновременная команда ALTER SYSTEM может перезаписать такие изменения. Такие инструменты могут просто добавлять новые настройки в конец, или они могут удалить дубликаты настроек и / или комментарии (как ALTER SYSTEM ).

Системное представление pg_file_settings может быть полезно для предварительного тестирования изменений в файлах конфигурации или для диагностики проблем, если сигнал SIGHUP не pg_file_settings желаемых результатов.

Взаимодействие параметров через SQL

QHB предоставляет три команды SQL для установки параметров конфигурации по умолчанию. Уже упомянутая команда ALTER SYSTEM предоставляет доступные для SQL средства изменения глобальных значений по умолчанию; это функционально эквивалентно редактированию qhb.conf. Кроме того, есть две команды, которые позволяют устанавливать значения по умолчанию для каждой базы данных или для каждой роли:

  • Команда ALTER DATABASE позволяет переопределять глобальные параметры для каждой базы данных.

  • Команда ALTER ROLE позволяет как глобальным настройкам, так и настройкам для каждой базы данных быть переопределенными пользовательскими значениями.

Значения, установленные с помощью ALTER DATABASE и ALTER ROLE, применяются только при запуске нового сеанса базы данных. Они переопределяют значения, полученные из файлов конфигурации или командной строки сервера, и составляют значения по умолчанию для оставшейся части сеанса. Обратите внимание, что некоторые параметры не могут быть изменены после запуска сервера, и поэтому не могут быть установлены с помощью этих команд (или перечисленных ниже).

После подключения клиента к базе данных QHB предоставляет две дополнительные команды SQL (и эквивалентные функции) для взаимодействия с локальными настройками конфигурации сеанса:

  • Команда SHOW позволяет проверить текущее значение всех параметров. Соответствующая функция - current_setting(setting_name text).

  • Команда SET позволяет изменять текущее значение тех параметров, которые могут быть установлены локально для сеанса; это не влияет на другие сеансы. Соответствующая функция set_config(setting_name, new_value, is_local).

Кроме того, системное представление pg_settings может использоваться для просмотра и изменения локальных значений сеанса:

  • Запрос этого представления аналогичен использованию SHOW ALL но предоставляет более подробную информацию. Это также более гибко, так как можно задавать условия фильтрации или объединяться с другими отношениями.

  • Использование UPDATE в этом представлении, в частности обновление столбца setting, эквивалентно выдаче команд SET. Например, эквивалентом

SET configuration_parameter TO DEFAULT;

является:

UPDATE pg_settings SET setting = reset_val WHERE name = 'configuration_parameter';

Взаимодействие параметров через оболочку

Помимо установки глобальных значений по умолчанию или добавления переопределений на уровне базы данных или роли, вы можете передавать настройки в QHB с помощью средств оболочки. И сервер, и клиентская библиотека libpq принимают значения параметров через оболочку.

  • Во время запуска сервера настройки параметров могут быть переданы команде qhb через параметр командной строки -c. Например,
qhb -c log_connections=yes -c log_destination='syslog'

Параметры, предоставляемые таким образом, переопределяют параметры, заданные с помощью qhb.conf или ALTER SYSTEM, поэтому их нельзя изменить глобально без перезапуска сервера.

  • При запуске клиентского сеанса через libpq настройки параметров можно указать с помощью переменной среды PGOPTIONS. Установленные таким образом настройки представляют собой значения по умолчанию для жизни сеанса, но не влияют на другие сеансы. По историческим причинам формат PGOPTIONS похож на тот, который используется при запуске команды qhb ; в частности, должен быть указан флаг -c. Например,
env PGOPTIONS="-c geqo=off -c statement_timeout=5min" psql

Другие клиенты и библиотеки могут предоставлять свои собственные механизмы через оболочку или иным образом, которые позволяют пользователю изменять настройки сеанса без непосредственного использования команд SQL.

Управление содержимым файла конфигурации

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

В дополнение к отдельным настройкам параметров файл qhb.conf может содержать директивы include, которые определяют другой файл для чтения и обработки, как если бы он был вставлен в файл конфигурации на данном этапе. Эта функция позволяет разделить файл конфигурации на физически отдельные части. Директивы include просто выглядят так:

include ’filename’

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

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

Файл qhb.conf также может содержать директивы include_dir, которые указывают весь каталог файлов конфигурации, который нужно включить. Это выглядит как

include_dir 'directory'

Неабсолютные имена каталогов берутся относительно каталога, содержащего ссылочный файл конфигурации. В указанном каталоге будут включены только файлы, не являющиеся каталогами, имена которых заканчиваются суффиксом .conf. Имена файлов, начинающиеся с cимвола . также игнорируется, чтобы избежать ошибок, поскольку такие файлы скрыты на некоторых платформах. Несколько файлов в каталоге include обрабатываются в порядке имен файлов (в соответствии с правилами языка C, т.е. цифрами перед буквами и заглавными буквами перед строчными).

Включаемые файлы или каталоги могут использоваться для логического разделения частей конфигурации базы данных, вместо того, чтобы иметь один большой файл qhb.conf. Рассмотрим компанию с двумя серверами баз данных, каждый с разным объемом памяти. Есть вероятные элементы конфигурации, которые будут совместно использоваться для таких вещей, как ведение журнала. Но связанные с памятью параметры на сервере будут различаться между двумя. И там могут быть специфические настройки сервера тоже. Один из способов справиться с этой ситуацией - разбить пользовательские изменения конфигурации вашего сайта на три файла. Вы можете добавить это в конец вашего файла qhb.conf чтобы включить их:

include 'shared.conf'
include 'memory.conf'
include 'server.conf'

Все системы будут иметь одинаковый shared.conf. Каждый сервер с определенным объемом памяти может использовать один и тот же memory.conf; у вас может быть один для всех серверов с 8 ГБ ОЗУ, другой для тех, у кого 16 ГБ. И, наконец, server.conf может содержать действительно специфическую для сервера информацию о конфигурации.

Другая возможность - создать каталог с файлами конфигурации и поместить эту информацию в файлы. Например, на каталог conf.d можно ссылаться в конце qhb.conf :

include_dir 'conf.d'

Затем вы можете назвать файлы в каталоге conf.d следующим образом:

00shared.conf
01memory.conf
02server.conf

Это соглашение об именах устанавливает четкий порядок загрузки этих файлов. Это важно, потому что будет использоваться только последний параметр, обнаруженный для определенного параметра, когда сервер читает файлы конфигурации. В этом примере что-то, установленное в conf.d/02server.conf, переопределит значение, установленное в .d/01memory.conf.

Вместо этого вы могли бы использовать этот подход для описательного именования файлов:

00shared.conf
01memory-8GB.conf
02server-foo.conf

Такое расположение дает уникальное имя для каждого варианта файла конфигурации. Это может помочь устранить неоднозначность, когда конфигурации нескольких серверов хранятся в одном месте, например в репозитории контроля версий. (Хранение файлов конфигурации базы данных под управлением версиями - это еще одна полезная практика).

Расположение файлов

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

Параметры расположения файлов конфигурации

data_directory (string)

Определяет основной файл конфигурации сервера (обычно называется qhb.conf). Этот параметр можно установить только при запуске сервера.

config_file (string)

Определяет основной файл конфигурации сервера (обычно называется qhb.conf). Этот параметр можно установить только в командной строке .

hba_file (string)

Указывает файл конфигурации для аутентификации на основе хоста (обычно называется qhb_hba.conf). Этот параметр можно установить только при запуске сервера.

external_pid_file (string)

Задает имя дополнительного файла идентификатора процесса (PID), который сервер должен создать для использования программами администрирования сервера. Этот параметр можно установить только при запуске сервера.

При установке по умолчанию ни один из вышеперечисленных параметров не устанавливается явно. Вместо этого каталог данных указывается параметром командной строки -D или переменной среды PGDATA, и все файлы конфигурации находятся в каталоге данных.

Если вы хотите сохранить файлы конфигурации в другом месте, кроме каталога данных, параметр командной строки qhb -D или переменная среды PGDATA должны указывать на каталог, содержащий файлы конфигурации, а параметр data_directory должен быть установлен в qhb.conf (или в командная строка), чтобы показать, где на самом деле находится каталог данных. Обратите внимание, что data_directory переопределяет -D и PGDATA для расположения каталога данных, но не для расположения файлов конфигурации.

При желании вы можете указать имена файлов конфигурации и их расположение по отдельности, используя параметры config_file, hba_file и/или ident_file. config_file может быть указан только в командной строке qhb, но остальные могут быть установлены в основном файле конфигурации. Если все три параметра плюс data_directory установлены явно, указывать -D или PGDATA не обязательно.

При установке любого из этих параметров относительный путь будет интерпретироваться относительно каталога, в котором запущен qhb.

Соединения и Аутентификация

Настройки соединения

listen_addresses (string)

  • Указывает адрес (а) TCP / IP, на котором сервер должен прослушивать соединения от клиентских приложений. Значение принимает форму разделенного запятыми списка имен хостов и / или числовых IP-адресов. Специальная запись * соответствует всем доступным IP-интерфейсам. Запись 0.0.0.0 позволяет прослушивать все адреса IPv4 и :: позволяет прослушивать все адреса IPv6. Если список пуст, сервер вообще не прослушивает ни один IP-интерфейс, и в этом случае для подключения к нему можно использовать только сокеты Unix-домена. Значением по умолчанию является localhost, что позволяет устанавливать только локальные « петлевые » соединения TCP / IP. В то время как аутентификация клиента (глава 20) позволяет детально контролировать, кто может получить доступ к серверу, listen_addresses контролирует, какие интерфейсы принимают попытки соединения, что может помочь предотвратить повторные запросы злонамеренного соединения на незащищенных сетевых интерфейсах. Этот параметр можно установить только при запуске сервера.

port (integer)

  • TCP-порт, который прослушивает сервер; 5432 по умолчанию. Обратите внимание, что один и тот же номер порта используется для всех IP-адресов, которые прослушивает сервер. Этот параметр можно установить только при запуске сервера.

max_connections (integer)

  • Определяет максимальное количество одновременных подключений к серверу базы данных. По умолчанию обычно используется 100 соединений, но может быть и меньше, если настройки ядра не будут его поддерживать (как определено во время initdb). Этот параметр можно установить только при запуске сервера.

  • При запуске резервного сервера вы должны установить для этого параметра то же или более высокое значение, чем на главном сервере. В противном случае запросы не будут разрешены на резервном сервере.

superuser_reserved_connections (integer)

  • Определяет количество « слотов » для соединений, которые зарезервированы для соединений суперпользователями QHB. В большинстве случаев соединения max_connections могут быть активными одновременно. Всякий раз, когда число активных одновременных подключений составляет не менее max_connections минус superuser_reserved_connections, новые подключения будут приниматься только для суперпользователей, и новые подключения репликации не будут приниматься.

  • Значение по умолчанию - три соединения. Значение должно быть меньше, чем max_connections. Этот параметр можно установить только при запуске сервера.

unix_socket_directories (string)

  • Указывает каталог сокетов Unix-домена, в которых сервер должен прослушивать соединения от клиентских приложений. Можно создать несколько сокетов, перечислив несколько каталогов, разделенных запятыми. Пробелы между записями игнорируются; окружите имя каталога двойными кавычками, если вам нужно включить в имя пробел или запятые. Пустое значение указывает, что прослушивание не происходит ни в одном из сокетов Unix-домена, и в этом случае для подключения к серверу могут использоваться только сокеты TCP / IP. Значением по умолчанию обычно является /tmp, но его можно изменить во время сборки. Этот параметр можно установить только при запуске сервера.

  • В дополнение к самому файлу сокета, который называется .s.PGSQL. nnnn .s.PGSQL. nnnn где nnnn - номер порта сервера, обычный файл с именем .s.PGSQL. nnnn .lock .s.PGSQL. nnnn .lock будет создан в каждом из каталогов unix_socket_directories. Ни один файл не должен быть удален вручную.

unix_socket_group (string)

  • Устанавливает группу-владельца сокетов Unix-домена. (Владельцем пользователя сокетов всегда является пользователь, запускающий сервер). В сочетании с параметром unix_socket_permissions это может использоваться в качестве дополнительного механизма контроля доступа для соединений Unix-домена. По умолчанию это пустая строка, которая использует группу по умолчанию пользователя сервера. Этот параметр можно установить только при запуске сервера.

unix_socket_permissions (integer)

  • Устанавливает права доступа для сокетов Unix-домена. Сокеты домена Unix используют обычный набор разрешений файловой системы Unix. Ожидается, что значением параметра будет числовой режим, указанный в формате, принятом системными вызовами chmod и umask. (Для использования обычного восьмеричного формата число должно начинаться с 0 (ноль)).

  • Разрешения по умолчанию - 0777, что означает, что любой может подключиться. Разумными альтернативами являются 0770 (только пользователь и группа, см. Также unix_socket_group ) и 0700 (только пользователь). (Обратите внимание, что для сокета Unix-домена только права на запись имеют значение, поэтому нет смысла устанавливать или отзывать разрешения на чтение или выполнение).

  • Этот параметр можно установить только при запуске сервера.

  • Этот параметр не имеет отношения к системам, особенно Solaris с Solaris 10, которые полностью игнорируют разрешения сокетов. Там можно достичь аналогичного эффекта, указав unix_socket_directories на каталог с разрешением поиска, ограниченным желаемой аудиторией. Этот параметр также не имеет значения в Windows, где нет сокетов Unix-домена.

bonjour (boolean)

  • Позволяет рекламировать существование сервера через Bonjour. По умолчанию выключено. Этот параметр можно установить только при запуске сервера.

bonjour_name (string)

  • Указывает имя службы Bonjour. Имя компьютера используется, если для этого параметра задана пустая строка ” (по умолчанию). Этот параметр игнорируется, если сервер не был скомпилирован с поддержкой Bonjour. Этот параметр можно установить только при запуске сервера.

tcp_keepalives_idle (integer)

  • Задает время бездействия сети, по истечении которого операционная система должна отправлять клиенту сообщение поддержки активности TCP. Если это значение указано без единиц измерения, оно принимается за секунды. Значение 0 (по умолчанию) выбирает операционную систему по умолчанию. Этот параметр поддерживается только в системах, которые поддерживают TCP_KEEPIDLE или эквивалентный параметр сокета, и в Windows; в других системах оно должно быть равно нулю. В сеансах, подключенных через сокет Unix-домена, этот параметр игнорируется и всегда читается как ноль.

tcp_keepalives_interval (integer)

  • Задает время, по истечении которого сообщение подтверждения активности TCP, которое не было подтверждено клиентом, должно быть повторно передано. Если это значение указано без единиц измерения, оно принимается за секунды. Значение 0 (по умолчанию) выбирает операционную систему по умолчанию. Этот параметр поддерживается только в системах, которые поддерживают TCP_KEEPINTVL или эквивалентный параметр сокета, и в Windows; в других системах оно должно быть равно нулю. В сеансах, подключенных через сокет Unix-домена, этот параметр игнорируется и всегда читается как ноль.

tcp_keepalives_count (integer)

  • Задает количество сообщений поддержки активности TCP, которые могут быть потеряны до того, как соединение сервера с клиентом будет считаться разорванным. Значение 0 (по умолчанию) выбирает операционную систему по умолчанию. Этот параметр поддерживается только в системах, которые поддерживают TCP_KEEPCNT или эквивалентную опцию сокета; в других системах оно должно быть равно нулю. В сеансах, подключенных через сокет Unix-домена, этот параметр игнорируется и всегда читается как ноль.

tcp_user_timeout (integer)

  • Задает время, в течение которого передаваемые данные могут оставаться неподтвержденными до принудительного закрытия TCP-соединения. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Значение 0 (по умолчанию) выбирает операционную систему по умолчанию. Этот параметр поддерживается только в системах, которые поддерживают TCP_USER_TIMEOUT ; в других системах оно должно быть равно нулю. В сеансах, подключенных через сокет Unix-домена, этот параметр игнорируется и всегда читается как ноль.

Аутентификация

authentication_timeout (integer)

  • Максимальное время, необходимое для завершения аутентификации клиента. Если потенциальный клиент не завершил протокол аутентификации за это время, сервер закрывает соединение. Это не позволяет зависшим клиентам занимать соединение бесконечно. Если это значение указано без единиц измерения, оно принимается за секунды. Значение по умолчанию составляет одну минуту (1m). Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

password_encryption (enum)

  • Если в CREATE ROLE или ALTER ROLE указан пароль, этот параметр определяет алгоритм, который будет использоваться для шифрования пароля. Значением по умолчанию является md5, в котором пароль хранится в виде хэша MD5 (также допускается on качестве псевдонима для md5 ). Установка этого параметра в scram-sha-256 зашифрует пароль с помощью SCRAM-SHA-256.

  • Обратите внимание, что старые клиенты могут не поддерживать механизм аутентификации SCRAM и, следовательно, не работать с паролями, зашифрованными с помощью SCRAM-SHA-256.

krb_server_keyfile (string)

  • Устанавливает расположение файла ключа сервера Kerberos. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

krb_caseins_users (boolean)

  • Устанавливает, должны ли имена пользователей GSSAPI обрабатываться без учета регистра. По умолчанию off (чувствительно к регистру). Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

db_user_namespace (boolean)

  • Этот параметр включает имена пользователей для каждой базы данных. По умолчанию он выключен. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

  • Если это включено, вы должны создавать пользователей как username@dbname. Когда username передается подключающимся клиентом, @ и имя базы данных добавляются к имени пользователя, и это специфичное для базы данных имя пользователя ищется сервером. Обратите внимание, что когда вы создаете пользователей с именами, содержащими @ в среде SQL, вам нужно будет указывать имя пользователя в кавычках.

  • Если этот параметр включен, вы все равно можете создавать обычных глобальных пользователей. Просто добавьте @ при указании имени пользователя в клиенте, например, joe@. Символ @ будет удален до того, как сервер найдет имя пользователя.

  • db_user_namespace вызывает различия в представлении имени пользователя клиента и сервера. Проверка подлинности всегда выполняется с именем пользователя сервера, поэтому методы проверки подлинности должны быть настроены для имени пользователя сервера, а не клиента. Поскольку md5 использует имя пользователя в качестве соли как на клиенте, так и на сервере, md5 нельзя использовать с db_user_namespace.

SSL

ssl (boolean)

  • Включает SSL- соединения. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. По умолчанию off.

ssl_ca_file (string)

  • Указывает имя файла, содержащего центр сертификации сервера SSL (CA). Относительные пути относятся к каталогу данных. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. По умолчанию пусто, что означает, что файл CA не загружен, и проверка сертификата клиента не выполняется.

ssl_cert_file (string)

  • Указывает имя файла, содержащего сертификат сервера SSL. Относительные пути относятся к каталогу данных. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. По умолчанию это server.crt.

ssl_crl_file (string)

  • Указывает имя файла, содержащего список отзыва сертификатов сервера SSL (CRL). Относительные пути относятся к каталогу данных. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. По умолчанию пусто, что означает, что файл CRL не загружен.

ssl_key_file (string)

  • Задает имя файла, содержащего закрытый ключ сервера SSL. Относительные пути относятся к каталогу данных. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. По умолчанию это server.key.

ssl_ciphers (string)

  • Задает список наборов шифров SSL, которые разрешено использовать для защищенных соединений. См. Страницу руководства по шифрам в пакете OpenSSL для ознакомления с синтаксисом этого параметра и списком поддерживаемых значений. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. Значением по умолчанию является HIGH:MEDIUM:+3DES:!aNULL. По умолчанию это обычно разумный выбор, если у вас нет особых требований к безопасности.
    Объяснение значения по умолчанию:

    • HIGH - Наборы шифров, которые используют шифры из группы HIGH (например, AES, Camellia, 3DES)

    • MEDIUM - Наборы шифров, которые используют шифры из группы MEDIUM (например, RC4, SEED)

    • +3DES - Порядок OpenSSL по умолчанию для HIGH проблематичен, потому что он заказывает 3DES выше, чем AES128. Это неправильно, потому что 3DES предлагает меньше безопасности, чем AES128, и это также намного медленнее. +3DES переупорядочивает его после всех других шифров HIGH и MEDIUM.

    • !aNULL - Отключает анонимные наборы шифров, которые не выполняют аутентификацию. Такие комплекты шифров уязвимы для атак «человек посередине» и поэтому не должны использоваться.

  • Доступные подробности комплекта шифров зависят от версии OpenSSL. Используйте команду openssl ciphers -v 'HIGH:MEDIUM:+3DES:!aNULL' чтобы увидеть фактические данные для текущей установленной версии OpenSSL. Обратите внимание, что этот список фильтруется во время выполнения в зависимости от типа ключа сервера.

ssl_prefer_server_ciphers (boolean)

  • Указывает, следует ли использовать настройки шифрования SSL сервера, а не настройки клиента. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. По умолчанию включено.

ssl_ecdh_curve (string)

  • Задает имя кривой для использования в обмене ключами ECDH. Он должен поддерживаться всеми подключенными клиентами. Это не обязательно должна быть та же кривая, которая используется ключом эллиптической кривой сервера. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. Значение по умолчанию - prime256v1.

  • Имена OpenSSL для наиболее распространенных кривых: prime256v1 (NIST P-256), secp384r1 (NIST P-384), secp521r1 (NIST P-521). Полный список доступных кривых можно openssl ecparam -list_curves с помощью команды openssl ecparam -list_curves. Не все из них можно использовать в TLS.

ssl_min_protocol_version (enum)

  • Устанавливает минимальную версию протокола SSL / TLS для использования. Допустимые значения: TLSv1, TLSv1.1, TLSv1.2, TLSv1.3. Старые версии библиотеки OpenSSL не поддерживают все значения; ошибка будет возникать, если выбрана неподдерживаемая настройка. Версии протокола до TLS 1.0, а именно версии 2 и 3 SSL, всегда отключены.

  • По умолчанию используется TLSv1, в основном для поддержки старых версий библиотеки OpenSSL. Возможно, вы захотите установить более высокое значение, если все программные компоненты могут поддерживать более новые версии протокола.

ssl_max_protocol_version (enum)

  • Устанавливает максимальную версию протокола SSL / TLS для использования. Допустимые значения такие же, как для ssl_min_protocol_version, с добавлением пустой строки, которая допускает любую версию протокола. По умолчанию разрешена любая версия. Установка максимальной версии протокола в основном полезна для тестирования или если у некоторых компонентов возникают проблемы при работе с более новым протоколом.

ssl_dh_params_file (string)

  • Указывает имя файла, содержащего параметры Диффи-Хеллмана, используемые для так называемого эфемерного семейства DH-шифров SSL. По умолчанию пусто, и в этом случае используются скомпилированные по умолчанию параметры DH. Использование пользовательских параметров DH уменьшает воздействие, если злоумышленнику удается взломать хорошо известные скомпилированные параметры DH. Вы можете создать свой собственный файл параметров DH с помощью команды openssl dhparam -out dhparams.pem 2048.

  • Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

ssl_passphrase_command (string)

  • Устанавливает внешнюю команду, которая будет вызываться, когда требуется получить ключевую фразу для расшифровки файла SSL, такого как закрытый ключ. По умолчанию этот параметр пуст, что означает, что используется встроенный механизм подсказок.

  • Команда должна распечатать парольную фразу на стандартный вывод и выйти с кодом 0. В значении параметра %p заменяется строкой приглашения. (Напишите %% для литерала %). Обратите внимание, что строка приглашения, вероятно, будет содержать пробелы, поэтому убедитесь, что в ней указаны соответствующие кавычки. Единственная новая строка удаляется с конца вывода, если она есть.

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

  • Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

ssl_passphrase_command_supports_reload (boolean)

  • Этот параметр определяет, будет ли команда passphrase, установленная ssl_passphrase_comman, также вызываться во время перезагрузки конфигурации, если файл ключа нуждается в парольной фразе. Если этот параметр отключен (по умолчанию), то ssl_passphrase_command будет игнорироваться во время перезагрузки, и конфигурация SSL не будет перезагружаться, если требуется пароль. Этот параметр подходит для команды, для запроса которой требуется TTY, который может быть недоступен во время работы сервера. Установка этого параметра в on может быть целесообразной, если, например, пароль получен из файла.

  • Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

Потребление ресурсов

Память

shared_buffers (integer)

  • Устанавливает объем памяти, используемый сервером базы данных для буферов общей памяти. Значение по умолчанию обычно составляет 128 мегабайт (128MB), но может быть меньше, если настройки ядра не будут его поддерживать (как определено во время initdb). Этот параметр должен быть не менее 128 килобайт. Тем не менее, настройки, значительно превышающие минимальные, обычно необходимы для хорошей производительности. Если это значение указано без единиц измерения, оно принимается как блоки, то есть байты BLCKSZ, обычно 8 КБ. (Значения BLCKSZ от значений по BLCKSZ изменяют минимальное значение). Этот параметр можно установить только при запуске сервера.

  • Если у вас есть выделенный сервер базы данных с 1 ГБ или более ОЗУ, разумное начальное значение для shared_buffers составляет 25% памяти в вашей системе. Существуют некоторые рабочие нагрузки, в которых эффективны даже большие настройки для shared_buffers, но поскольку QHB также опирается на кэш операционной системы, маловероятно, что выделение более 40% ОЗУ для shared_buffers будет работать лучше, чем меньшее количество. Большие настройки для shared_buffers обычно требуют соответствующего увеличения max_wal_size, чтобы распространить процесс записи большого количества новых или измененных данных на более длительный период времени.

  • В системах с менее чем 1 ГБ ОЗУ необходим меньший процент ОЗУ, чтобы оставить достаточно места для операционной системы.

huge_pages (enum)

  • Определяет, запрашиваются ли огромные страницы для основной области общей памяти. Допустимые значения: try (по умолчанию), on и off. Если huge_pages настроили try huge_pages, сервер попытается запросить огромные страницы, но в случае сбоя вернется к huge_pages по умолчанию. При on, запрос больших страниц будет препятствовать запуску сервера. С off огромные страницы не будут запрашиваться.

  • В настоящее время этот параметр поддерживается только в Linux. Эта настройка игнорируется в других системах, если задана try.

  • Использование огромных страниц приводит к уменьшению таблиц страниц и сокращению затрат времени ЦП на управление памятью, что повышает производительность.

  • Обратите внимание, что этот параметр влияет только на основную область общей памяти. Операционные системы, такие как Linux, FreeBSD и Illumos, также могут автоматически использовать огромные страницы (также известные как « супер » или « большие » страницы) для обычного распределения памяти без явного запроса QHB. В Linux это называется « прозрачные огромные страницы » (ТНР). Известно, что эта функция может привести к снижению производительности QHB для некоторых пользователей в некоторых версиях Linux, поэтому ее использование в настоящее время не рекомендуется (в отличие от явного использования huge_pages).

temp_buffers (integer)

  • Устанавливает максимальный объем памяти, используемый для временных буферов в каждом сеансе базы данных. Это локальные буферы сеанса, используемые только для доступа к временным таблицам. Если это значение указано без единиц измерения, оно принимается как блоки, то есть байты BLCKSZ, обычно 8 КБ. По умолчанию используется восемь мегабайт (8MB). (Если BLCKSZ не равен 8 КБ, значение по умолчанию масштабируется пропорционально ему). Этот параметр можно изменить в отдельных сеансах, но только перед первым использованием временных таблиц в сеансе; Последующие попытки изменить значение не будут влиять на этот сеанс.

  • Сеанс будет распределять временные буферы по мере необходимости до предела, заданного temp_buffers. Стоимость установки большого значения в сеансах, которые на самом деле не нуждаются во многих временных буферах, составляет только дескриптор буфера, или около 64 байтов, за приращение в temp_buffers. Однако, если буфер фактически используется, для него будут использованы дополнительные 8192 байта (или, как BLCKSZ байты BLCKSZ).

max_prepared_transactions (integer)

  • Устанавливает максимальное количество транзакций, которые могут одновременно находиться в « подготовленном » состоянии (см. PREPARE TRANSACTION ). Установка этого параметра в ноль (по умолчанию) отключает функцию подготовленной транзакции. Этот параметр можно установить только при запуске сервера.

  • Если вы не планируете использовать подготовленные транзакции, этот параметр должен быть установлен на ноль, чтобы предотвратить случайное создание подготовленных транзакций. Если вы используете подготовленные транзакции, вы, вероятно, захотите, чтобы max_prepared_transactions был по крайней мере таким же большим, как max_connections, чтобы у каждого сеанса могла быть ожидающая подготовленная транзакция.

  • При запуске резервного сервера вы должны установить для этого параметра то же или более высокое значение, чем на главном сервере. В противном случае запросы не будут разрешены на резервном сервере.

work_mem (integer)

  • Устанавливает максимальный объем памяти, который будет использоваться операцией запроса (такой как сортировка или хеш-таблица) перед записью во временные файлы на диске. Если это значение указано без единиц измерения, оно принимается за килобайты. Значение по умолчанию составляет четыре мегабайта (4MB). Обратите внимание, что для сложного запроса несколько операций сортировки или хеширования могут выполняться параллельно; каждой операции будет разрешено использовать столько памяти, сколько указано в этом значении, прежде чем она начнет записывать данные во временные файлы. Кроме того, несколько запущенных сеансов могут выполнять такие операции одновременно. Следовательно, общая используемая память может многократно превышать значение work_mem ; этот факт необходимо учитывать при выборе значения. Операции сортировки используются для ORDER BY, DISTINCT и объединений слиянием. Хеш-таблицы используются в хеш-соединениях, агрегации на основе хеша и обработке подзапросов IN основе хеша.

maintenance_work_mem (integer)

  • Задает максимальный объем памяти, который будет использоваться операциями обслуживания, такими как VACUUM, CREATE INDEX и ALTER TABLE ADD FOREIGN KEY. Если это значение указано без единиц измерения, оно принимается за килобайты. По умолчанию это 64 мегабайта (64MB). Поскольку только одна из этих операций может быть выполнена за один раз сеансом базы данных, и у установки обычно нет многих из них, работающих одновременно, можно безопасно установить это значение значительно больше, чем work_mem. Большие настройки могут повысить производительность для очистки и восстановления дампов базы данных.

  • Обратите внимание, что при запуске autovacuum, до времени autovacuum_max_workers эта память может быть выделена, поэтому будьте осторожны, чтобы не установить слишком высокое значение по умолчанию. Это может быть полезно для контроля, отдельно устанавливая autovacuum_work_mem.

autovacuum_work_mem (integer)

  • Указывает максимальный объем памяти, который будет использоваться каждым рабочим процессом автоочистки. Если это значение указано без единиц измерения, оно принимается за килобайты. По умолчанию используется значение -1, указывающее, что вместо этого следует использовать значение maintenance_work_mem. Этот параметр не влияет на поведение VACUUM при запуске в других контекстах.

max_stack_depth (integer)

  • Задает максимальную безопасную глубину стека выполнения сервера. Идеальным параметром для этого параметра является фактический предел размера стека, установленный ядром (установленный ulimit -s или локальным эквивалентом), за вычетом запаса прочности в мегабайте или около того. Запас безопасности необходим, потому что глубина стека проверяется не в каждой подпрограмме на сервере, а только в ключевых потенциально-рекурсивных подпрограммах. Если это значение указано без единиц измерения, оно принимается за килобайты. Значение по умолчанию составляет два мегабайта (2MB), что является консервативно небольшим и вряд ли приведет к сбою. Однако он может быть слишком маленьким, чтобы разрешить выполнение сложных функций. Только суперпользователи могут изменять эту настройку.

  • Установка max_stack_depth выше фактического лимита ядра будет означать, что убегающая рекурсивная функция может привести к сбою отдельного внутреннего процесса. На платформах, где QHB может определить ограничение ядра, сервер не допустит, чтобы для этой переменной было установлено небезопасное значение. Однако не все платформы предоставляют информацию, поэтому при выборе значения рекомендуется соблюдать осторожность.

shared_memory_type (enum)

  • Определяет реализацию совместно используемой памяти, которую сервер должен использовать для основной области совместно используемой памяти, которая содержит совместно используемые буферы QHB и другие совместно используемые данные. Возможные значения: mmap (для анонимной разделяемой памяти, выделенной с помощью mmap ), sysv (для разделяемой памяти System V, выделенной с помощью shmget ). Не все значения поддерживаются на всех платформах; первая поддерживаемая опция используется по умолчанию для этой платформы. Использование опции sysv, которая не используется по умолчанию на какой-либо платформе, обычно не рекомендуется, потому что обычно для нее требуются нестандартные настройки ядра для больших выделений .

dynamic_shared_memory_type (enum)

  • Определяет реализацию динамической разделяемой памяти, которую должен использовать сервер. Возможные значения: posix (для разделяемой памяти POSIX, выделенной с помощью shm_open ), sysv (для разделяемой памяти System V, выделенной с помощью shmget), windows (для разделяемой памяти Windows) и mmap (для имитации разделяемой памяти с использованием отображенных в памяти файлов, хранящихся в данных каталог). Не все значения поддерживаются на всех платформах; первая поддерживаемая опция используется по умолчанию для этой платформы. Использование параметра mmap, который не используется по умолчанию на любой платформе, обычно не рекомендуется, поскольку операционная система может многократно записывать измененные страницы на диск, увеличивая нагрузку на ввод-вывод системы; однако это может быть полезно для отладки, когда каталог pg_dynshmem хранится на диске RAM, или когда другие средства общей памяти недоступны.

Диск

temp_file_limit (integer)

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

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

Использование ресурсов ядра

max_files_per_process (integer)

  • Устанавливает максимальное количество одновременно открытых файлов, разрешенное для каждого подпроцесса сервера. По умолчанию используется тысяча файлов. Если ядро применяет безопасный лимит для каждого процесса, вам не нужно беспокоиться об этом параметре. Но на некоторых платформах (особенно в большинстве систем BSD) ядро позволяет отдельным процессам открывать гораздо больше файлов, чем может реально поддерживать система, если все процессы пытаются открыть такое количество файлов. Если вы обнаружите, что видите « Слишком много открытых файлов », попробуйте уменьшить этот параметр. Этот параметр можно установить только при запуске сервера.

Определение предела стоимости работы процесса vacuum

Во время выполнения команд VACUUM и ANALYZE система поддерживает внутренний счетчик, который отслеживает оценочную стоимость различных выполняемых операций ввода-вывода. Когда накопленная стоимость достигает предела (указанного в vacuum_cost_limit), процесс, выполняющий операцию, будет vacuum_cost_limit в спящем режиме в течение короткого периода времени, как указано в vacuum_cost_delay. Затем он сбросит счетчик и продолжит выполнение.

Цель этой функции - позволить администраторам уменьшить влияние ввода / вывода этих команд на одновременную работу базы данных. Во многих ситуациях не важно, чтобы команды обслуживания, такие как VACUUM и ANALYZE быстро заканчивались; однако, как правило, очень важно, чтобы эти команды не оказывали значительного влияния на способность системы выполнять другие операции с базой данных. Задержка вакуума, основанная на затратах, позволяет администраторам достичь этого.

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

vacuum_cost_delay (с floating point)

  • Время, в течение которого процесс будет находиться в спящем режиме после превышения предела стоимости. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Значение по умолчанию равно нулю, что отключает функцию задержки вакуума на основе стоимости. Положительные значения позволяют производить VACUUM на основе затрат.

  • При использовании vacuum, основанного на стоимости, подходящие значения для vacuum_cost_delay обычно довольно малы, возможно, менее 1 миллисекунды. Несмотря на то, что в параметре vacuum_cost_delay можно задать значения в долях миллисекунды, такие задержки могут не измеряться точно на старых платформах. На таких платформах увеличение расхода ресурсов VACUUM превышающее то, что вы получаете на 1 мс, потребует изменения других параметров стоимости вакуума. Тем не менее, вы должны сохранять vacuum_cost_delay таким же небольшим, как ваша платформа будет постоянно измерять; большие задержки не помогают.

vacuum_cost_page_hit (integer)

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

vacuum_cost_page_miss (integer)

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

vacuum_cost_page_dirty (integer)

  • Ориентировочная стоимость взимается, когда вакуум модифицирует блок, который был ранее чистым. Он представляет собой дополнительный ввод / вывод, необходимый для повторной очистки грязного блока на диске. Значением по умолчанию является 20.

vacuum_cost_limit (integer)

  • Накопленная стоимость, которая заставит процесс уборки спать. Значение по умолчанию составляет 200.

Заметка
Существуют определенные операции, которые удерживают критические блокировки и поэтому должны завершаться как можно быстрее. Вакуумные задержки на основе затрат не возникают во время таких операций. Поэтому возможно, что стоимость накапливается намного выше, чем указанный предел. Чтобы избежать бесполезно длительных задержек в таких случаях, фактическая задержка рассчитывается как vacuum_cost_delay * accumulated_balance / vacuum_cost_limit с максимумом vacuum_cost_delay * 4.

Фоновая запись

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

bgwriter_delay (integer)

  • Определяет задержку между раундами активности для фонового писателя. В каждом раунде писатель выдает записи для некоторого количества грязных буферов (управляемых следующими параметрами). Затем он спит по длине bgwriter_delay и повторяется. Когда в пуле буферов нет грязных буферов, он переходит в более длительный режим bgwriter_delay независимо от bgwriter_delay. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Значение по умолчанию составляет 200 миллисекунд (200 200ms). Обратите внимание, что во многих системах эффективное разрешение задержек сна составляет 10 миллисекунд; установка значения bgwriter_delay, не кратного 10, может иметь те же результаты, что и установка следующего более высокого значения, кратного 10. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

bgwriter_lru_maxpages (integer)

  • В каждом раунде фоновый писатель будет записывать не более этого количества буферов. Установка этого значения в ноль отключает фоновую запись. (Обратите внимание, что контрольные точки, которые управляются отдельным выделенным вспомогательным процессом, не затрагиваются). Значение по умолчанию - 100 буферов. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

bgwriter_lru_multiplier (с floating point)

  • Количество грязных буферов, записанных в каждом раунде, основано на количестве новых буферов, которые были необходимы серверным процессам во время последних раундов. Средняя потребность за последнее время умножается на bgwriter_lru_multiplier чтобы получить оценку количества буферов, которое потребуется в следующем раунде. Грязные буферы записываются до тех пор, пока не появится столько чистых, многоразовых буферов. (Тем не менее, не более чем буферы bgwriter_lru_maxpages будут записываться за раунд). Таким образом, настройка 1.0 представляет « своевременную » политику записи именно того количества буферов, которое, по прогнозам, необходимо. Большие значения обеспечивают некоторую защиту от всплесков спроса, в то время как меньшие значения преднамеренно оставляют записи для серверных процессов. По умолчанию это 2.0. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

bgwriter_flush_after (integer)

  • Всякий раз, когда фоновое устройство записи записывает больше этого объема данных, попытайтесь заставить ОС выполнить эти записи в основное хранилище. Это ограничит количество «грязных» данных в кеше страниц ядра, уменьшая вероятность зависаний при fsync в конце контрольной точки или когда ОС записывает данные большими пакетами в фоновом режиме. Зачастую это приводит к значительному снижению задержки транзакций, но также есть некоторые случаи, особенно с рабочими нагрузками, которые больше, чем shared_buffers, но меньше, чем кеш страниц ОС, где производительность может снизиться. Этот параметр может не повлиять на некоторые платформы. Если это значение указано без единиц измерения, оно принимается как блоки, то есть байты BLCKSZ, обычно 8 КБ. Допустимый диапазон: от 0, что отключает принудительную обратную запись, до 2MB. По умолчанию 512kB в Linux, 0 другом месте. (Если BLCKSZ не равен 8 КБ, значения по умолчанию и максимальные значения масштабируются пропорционально ему). Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

Меньшие значения bgwriter_lru_maxpages и bgwriter_lru_multiplier уменьшают дополнительную нагрузку ввода-вывода, вызываемую фоновым bgwriter_lru_maxpages bgwriter_lru_multiplier, но повышают вероятность того, что серверным процессам придется выполнять записи для себя, что задерживает интерактивные запросы.

Асинхронное поведение

effective_io_concurrency (integer)

Устанавливает количество одновременных операций дискового ввода-вывода, которые, как ожидает QHB, могут выполняться одновременно. Увеличение этого значения приведет к увеличению числа операций ввода-вывода, которые каждый отдельный сеанс QHB пытается инициировать параллельно. Допустимый диапазон: от 1 до 1000 или ноль для отключения выдачи асинхронных запросов ввода-вывода. В настоящее время этот параметр влияет только на сканирование кучи растровых изображений.

Для магнитных дисков хорошей отправной точкой для этого параметра является количество отдельных дисков, содержащих полосу RAID 0 или зеркало RAID 1, используемое для базы данных. (Для RAID 5 диск четности не должен учитываться). Однако, если база данных часто занята несколькими запросами, выполняемыми в параллельных сеансах, более низких значений может быть достаточно для сохранения дискового массива занятым. Значение выше, чем необходимо, чтобы диски были заняты, приведет только к дополнительной загрузке ЦП. SSD-накопители и другие хранилища на основе памяти часто могут обрабатывать много одновременных запросов, поэтому наилучшим значением могут быть сотни.

Асинхронный ввод-вывод зависит от эффективной функции posix_fadvise, которой нет в некоторых операционных системах. Если функция отсутствует, то установка этого параметра в любое значение, кроме нуля, приведет к ошибке. В некоторых операционных системах (например, Solaris) функция присутствует, но фактически ничего не делает.

В поддерживаемых системах по умолчанию установлено значение 1, в противном случае - 0. Это значение можно переопределить для таблиц в определенном табличном пространстве, установив параметр табличного пространства с тем же именем (см. ALTER TABLESPACE).

max_worker_processes (integer)

Устанавливает максимальное количество фоновых процессов, которые может поддерживать система. Этот параметр можно установить только при запуске сервера. По умолчанию это 8.

При запуске резервного сервера вы должны установить для этого параметра то же или более высокое значение, чем на главном сервере. В противном случае запросы не будут разрешены на резервном сервере.

Изменяя это значение, рассмотрите также настройку max_parallel_workers, max_parallel_maintenance_workers и max_parallel_workers_per_gather.

max_parallel_workers_per_gather (integer)

Устанавливает максимальное количество рабочих, которое может быть запущено одним узлом Gather или Gather Merge. Параллельные рабочие берутся из пула процессов, установленных max_worker_processes, ограниченного max_parallel_workers. Обратите внимание, что запрошенное количество потоков может быть недоступно во время выполнения. Если это произойдет, план будет работать с меньшим количеством потоков, чем ожидалось, что может быть неэффективным. Значение по умолчанию - 2. Установка этого значения в 0 отключает параллельное выполнение запроса.

Обратите внимание, что параллельные запросы могут потреблять значительно больше ресурсов, чем непараллельные запросы, потому что каждый рабочий процесс является совершенно отдельным процессом, который оказывает примерно то же влияние на систему, что и дополнительный пользовательский сеанс. Это следует учитывать при выборе значения для этого параметра, а также при настройке других параметров, управляющих использованием ресурсов, таких как work_mem. Ограничения ресурсов, такие как work_mem, применяются индивидуально к каждому потоку, что означает, что общее использование может быть намного выше для всех процессов, чем обычно для любого отдельного процесса. Например, параллельный запрос с использованием 4 рабочих может использовать до 5 раз больше процессорного времени, памяти, пропускной способности ввода / вывода и т. д. Как запрос, который вообще не использует рабочих.

max_parallel_maintenance_workers (integer)

Устанавливает максимальное количество параллельных рабочих, которые могут быть запущены одной служебной командой. В настоящее время единственной командой параллельной утилиты, которая поддерживает использование параллельных рабочих, является CREATE INDEX, и только при построении индекса B-дерева. Параллельные рабочие берутся из пула процессов, установленных max_worker_processes, ограниченного max_parallel_workers. Обратите внимание, что запрошенное количество потоков может быть недоступно во время выполнения. Если это произойдет, работа утилиты будет выполняться с меньшим количеством потоков, чем ожидалось. Значение по умолчанию - 2. Установка этого значения в 0 отключает использование параллельных рабочих утилитными командами.

Обратите внимание, что параллельные служебные команды не должны занимать существенно больше памяти, чем эквивалентные непараллельные операции. Эта стратегия отличается от стратегии параллельного запроса, где ограничения ресурсов обычно применяются для каждого рабочего процесса. Параллельные служебные команды рассматривают ограничение ресурса maintenance_work_mem как ограничение, которое применяется ко всей служебной команде независимо от количества параллельных рабочих процессов. Однако параллельные служебные команды могут по-прежнему потреблять значительно больше ресурсов ЦП и пропускной способности ввода-вывода.

max_parallel_workers (integer)

Устанавливает максимальное количество рабочих, которое система может поддерживать для параллельных операций. Значение по умолчанию равно 8. При увеличении или уменьшении этого значения также следует рассмотреть возможность настройки max_parallel_maintenance_workers и max_parallel_workers_per_gather. Также обратите внимание, что настройка для этого значения, которая больше, чем max_worker_processes, не будет иметь никакого эффекта, поскольку параллельные рабочие берутся из пула рабочих процессов, созданного этим параметром.

backend_flush_after (integer)

Всякий раз, когда за один сервер было записано больше этого объема данных, попытайтесь заставить ОС выполнить эти записи в базовое хранилище. Это ограничит количество «грязных» данных в кеше страниц ядра, уменьшая вероятность зависаний при fsync в конце контрольной точки или когда ОС записывает данные большими пакетами в фоновом режиме. Зачастую это приводит к значительному снижению задержки транзакций, но также есть некоторые случаи, особенно с рабочими нагрузками, которые больше, чем shared_buffers, но меньше, чем кеш страниц ОС, где производительность может снизиться. Этот параметр может не повлиять на некоторые платформы. Если это значение указано без единиц измерения, оно принимается как блоки, то есть байты BLCKSZ, обычно 8 КБ. Допустимый диапазон: от 0, что отключает принудительную обратную запись, до 2MB. По умолчанию 0, т.е. принудительная обратная запись отсутствует. (Если BLCKSZ не 8 КБ, максимальное значение пропорционально ему).

old_snapshot_threshold (integer)

Устанавливает минимальный период времени, в течение которого снимок запроса может использоваться без риска возникновения ошибки « снимок слишком старый » при использовании снимка. Данные, которые были мертвы дольше, чем этот порог, могут быть удалены. Это может помочь предотвратить вздутие живота на снимках, которые остаются в использовании в течение длительного времени. Чтобы предотвратить неверные результаты из-за очистки данных, которые в противном случае были бы видны для снимка, генерируется ошибка, когда снимок старше этого порога, и снимок используется для чтения страницы, которая была изменена с момента создания снимка.

Если это значение указано без единиц измерения, оно принимается за минуты. Значение -1 (по умолчанию) отключает эту функцию, эффективно устанавливая предел возраста снимка бесконечность. Этот параметр можно установить только при запуске сервера.

Полезные значения для производственной работы, вероятно, варьируются от небольшого количества часов до нескольких дней. Небольшие значения (например, 0 или 1min) допустимы только потому, что иногда они могут быть полезны для тестирования. Несмотря на то, что допустимо значение до 60d, имейте в виду, что во многих рабочих нагрузках экстремальное раздувание или изменение идентификатора транзакции может происходить в гораздо более короткие периоды времени.

Когда эта функция включена, освобожденное пространство в конце отношения не может быть освобождено для операционной системы, так как это может удалить информацию, необходимую для обнаружения условия « снимок слишком старый ». Все пространство, выделенное для отношения, остается связанным с этим отношением для повторного использования только в этом отношении, если только оно явно не освобождено (например, с VACUUM FULL ).

Этот параметр не пытается гарантировать, что ошибка будет сгенерирована при любых конкретных обстоятельствах. Фактически, если правильные результаты могут быть сгенерированы из (например) курсора, который материализовал набор результатов, не будет сгенерировано никакой ошибки, даже если нижележащие строки в ссылочной таблице были удалены. Некоторые таблицы невозможно безопасно очистить на ранней стадии, поэтому этот параметр не будет затронут, например системные каталоги. Для таких таблиц этот параметр не уменьшит раздувание и не создаст возможность ошибки « снимок слишком старый » при сканировании.

Журнал упреждающей записи (wal)

Для получения дополнительной информации о настройке этих параметров см. раздел Конфигурация WAL.

Настройки

wal_level (enum)

  • wal_level определяет, сколько информации записывается в WAL. Значение по умолчанию - replica, которая записывает достаточно данных для поддержки архивации и репликации WAL, включая выполнение запросов только для чтения на резервном сервере. minimal удаляет все журналы, кроме информации, необходимой для восстановления после сбоя или немедленного выключения. Наконец, logical добавляет информацию, необходимую для поддержки логического декодирования. Каждый уровень включает информацию, зарегистрированную на всех более низких уровнях. Этот параметр можно установить только при запуске сервера.

  • На minimal уровне WAL-протоколирование некоторых массовых операций может быть безопасно пропущено, что может значительно ускорить эти операции (см. раздел Отключить архивацию WAL и потоковую репликацию). Операции, в которых может применяться эта оптимизация, включают в себя:

    • CREATE TABLE AS

    • CREATE INDEX

    • CLUSTER

    • COPY в таблицы, которые были созданы или усечены в одной транзакции

  • Но минимальный WAL не содержит достаточно информации для восстановления данных из базовой резервной копии и журналов WAL, поэтому для включения архивации WAL (archive_mode) и потоковой репликации необходимо использовать replica или более позднюю версию.

  • На logical уровне регистрируется та же информация, что и для replica, плюс информация, необходимая для извлечения наборов логических изменений из WAL. Использование logical уровня увеличит объем WAL, особенно если многие таблицы сконфигурированы для REPLICA IDENTITY FULL и выполняется много операторов UPDATE и DELETE.

fsync (boolean)

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

  • Хотя отключение fsync часто приводит к повышению производительности, это может привести к неустранимому повреждению данных в случае сбоя питания или сбоя системы. Таким образом, рекомендуется отключать fsync случае, если вы можете легко воссоздать всю базу данных из внешних данных.

  • Примеры безопасных обстоятельств для отключения fsync включают начальную загрузку нового кластера базы данных из файла резервной копии, использование кластера базы данных для обработки пакета данных, после которого база данных будет выброшена и воссоздана, или для базы данных только для чтения клон, который часто воссоздается и не используется для отработки отказа. Высококачественное оборудование само по себе не является достаточным основанием для отключения fsync.

  • Для надежного восстановления при включении fsync необходимо принудительно установить все измененные буферы в ядре в долговременное хранилище. Это можно сделать, когда кластер выключен или когда fsync, запустив initdb --sync-only, sync, размонтирование файловой системы или перезагрузку сервера.

  • Во многих ситуациях отключение synchronous_commit для некритических транзакций может обеспечить большую потенциальную выгоду производительности при отключении fsync без сопутствующего риска повреждения данных.

  • fsync можно установить только в файле qhb.conf или в командной строке сервера. Если вы отключите этот параметр, также рассмотрите возможность отключения full_page_writes.

synchronous_commit (enum)

  • Указывает, будет ли фиксация транзакции ожидать записи WAL на диск, прежде чем команда вернет клиенту указание «успех». Допустимые значения: on, remote_apply, remote_write, local и off. По умолчанию безопасная настройка включена. В off состоянии возможна задержка между тем, когда клиенту сообщается об успехе, и когда транзакция действительно гарантированно защищена от сбоя сервера. (Максимальная задержка в три раза больше wal_writer_delay). В отличие от fsync, off этого параметра не создает риска несогласованности базы данных: сбой операционной системы или базы данных может привести к потере некоторых недавних якобы зафиксированных транзакций, но состояние базы данных будет быть так же, как если бы эти транзакции были прерваны чисто. Таким образом, отключение synchronous_commit может быть полезной альтернативой, когда производительность важнее точной уверенности в долговечности транзакции. Для получения дополнительной информации см. раздел Асинхронный коммит.

  • Если synchronous_standby_names не является пустым, этот параметр также определяет, будет ли фиксация транзакции ожидать репликацию своих записей WAL на резервный сервер (ы). При on фиксация будет ожидать до тех пор, пока ответы из текущих синхронных резервных копий не укажут, что они получили запись фиксации транзакции и сбросили ее на диск. Это гарантирует, что транзакция не будет потеряна, если как основной, так и все синхронные резервные серверы не повредят хранилище своей базы данных. Если задано значение remote_apply, коммиты будут ждать, пока ответы из текущего синхронного резерва (-ов) не укажут, что они получили запись фиксации транзакции и применили ее, так что она стала видимой для запросов в резервах. Когда установлено значение remote_write, коммиты будут ждать, пока ответы из текущего синхронного резерва (-ов) не remote_write, что они получили запись фиксации транзакции и записали ее в свою операционную систему. Этот параметр достаточен для обеспечения сохранения данных даже в случае сбоя резервного экземпляра QHB, но не в том случае, если резервный переносит сбой на уровне операционной системы, поскольку данные не обязательно достигли стабильного хранилища в резервном режиме. Наконец, настройка local заставляет коммиты ждать локального сброса на диск, но не репликации. Это обычно нежелательно, когда используется синхронная репликация, но предоставляется для полноты.

  • Если synchronous_standby_names пусто, параметры on, remote_apply, remote_write и local обеспечивают одинаковый уровень синхронизации: транзакция фиксирует только ожидание локальной загрузки на диск.

  • Этот параметр может быть изменен в любое время; Поведение любой транзакции определяется настройкой, действующей при ее фиксации. Поэтому возможно и полезно, чтобы некоторые транзакции выполнялись синхронно, а другие - асинхронно. Например, чтобы одна транзакция с несколькими состояниями фиксировалась асинхронно, когда значение по умолчанию противоположное, введите SET LOCAL synchronous_commit TO OFF в транзакции.

wal_sync_method (enum)

  • Метод, используемый для принудительного обновления WAL на диск. Если fsync выключен, то этот параметр не имеет значения, поскольку обновления файла WAL вообще не будут принудительно обновляться. Возможные значения:

    • open_datasync (запись файлов WAL с опцией open() O_DSYNC)

    • fdatasync (вызывать fdatasync() при каждом коммите)

    • fsync (вызывать fsync() при каждом коммите)

    • fsync_writethrough (вызывать fsync() при каждом fsync_writethrough, вызывая сквозную запись любого дискового кэша записи)

    • open_sync (запись файлов WAL с опцией open() O_SYNC)

  • open_* также используют O_DIRECT если доступно. Не все эти варианты доступны на всех платформах. По умолчанию это первый метод в приведенном выше списке, который поддерживается платформой, за исключением того, что fdatasync является значением по умолчанию в Linux. Значение по умолчанию не обязательно идеально; может потребоваться изменить этот параметр или другие аспекты конфигурации вашей системы, чтобы создать безопасную конфигурацию или достичь оптимальной производительности. Эти аспекты обсуждаются в разделе Надежность. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

full_page_writes (boolean)

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

  • Отключение этого параметра ускоряет нормальную работу, но может привести к неисправимому повреждению данных или повреждению данных без вывода сообщений после сбоя системы. Риски аналогичны отключению fsync, хотя и меньше, и его следует отключать только на основании тех же обстоятельств, которые рекомендованы для этого параметра.

  • Отключение этого параметра не влияет на использование архивации WAL для восстановления на определенный момент времени (PITR) (см. раздел Непрерывное архивирование и восстановление на момент времени (PITR)).

  • Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. По умолчанию включено.

wal_log_hints (boolean)

  • Когда этот параметр включен, сервер QHB записывает все содержимое каждой страницы диска в WAL во время первой модификации этой страницы после контрольной точки, даже для некритических модификаций так называемых битов подсказок.

  • Если контрольные суммы данных включены, обновления битов подсказок всегда регистрируются в WAL, и этот параметр игнорируется. Вы можете использовать этот параметр, чтобы проверить, сколько дополнительных журналов WAL произойдет, если в вашей базе данных будут включены контрольные суммы данных.

  • Этот параметр можно установить только при запуске сервера. Значение по умолчанию off.

wal_compression (boolean)

  • Когда этот параметр включен, сервер QHB сжимает полный образ страницы, записанный в WAL, когда full_page_writes включен или во время основного резервного копирования. Сжатый образ страницы будет распакован во время воспроизведения WAL. Значение по умолчанию off. Только суперпользователи могут изменять эту настройку.

  • Включение этого параметра может уменьшить объем WAL без увеличения риска неустранимого повреждения данных, но за счет некоторого дополнительного ЦП, потраченного на сжатие во время ведения журнала WAL и на декомпрессию во время воспроизведения WAL.

wal_buffers (integer)

  • Объем общей памяти, используемой для данных WAL, которые еще не были записаны на диск. Значение по умолчанию -1 выбирает размер, равный 1/32 (около 3%) shared_buffers, но не менее 64kB не больше, чем размер одного сегмента WAL, обычно 16MB. Это значение может быть установлено вручную, если автоматический выбор слишком велик или слишком мал, но любое положительное значение менее 32kB будет рассматриваться как 32kB. Если это значение указано без единиц измерения, оно принимается как блоки WAL, то есть байты XLOG_BLCKSZ, обычно 8 КБ. Этот параметр можно установить только при запуске сервера.

  • Содержимое буферов WAL записывается на диск при каждой фиксации транзакции, поэтому крайне большие значения вряд ли обеспечат значительное преимущество. Однако установка этого значения как минимум в несколько мегабайт может улучшить производительность записи на занятом сервере, где одновременно фиксируются многие клиенты. Автонастройка, выбранная по умолчанию, равной -1, должна в большинстве случаев давать приемлемые результаты.

wal_writer_delay (integer)

  • Определяет, как часто писатель WAL сбрасывает WAL во временных терминах. После сброса WAL писатель спит в течение отрезка времени, указанного в wal_writer_delay, если только он не проснулся раньше из-за асинхронной фиксации транзакции. Если последний сброс произошел меньше, чем wal_writer_delay назад, и с тех пор был произведен WAL меньше, чем wal_writer_flush_after, то WAL записывается только в операционную систему, а не на диск. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Значение по умолчанию составляет 200 миллисекунд (200 200ms ). Обратите внимание, что во многих системах эффективное разрешение задержек сна составляет 10 миллисекунд; установка для wal_writer_delay значения, не кратного 10, может иметь те же результаты, что и установка следующего более высокого значения, кратного 10. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

wal_writer_flush_after (integer)

  • Определяет, как часто писатель WAL сбрасывает WAL в объемном выражении. Если последний сброс произошел меньше, чем wal_writer_delay назад, и с тех пор был произведен WAL меньше, чем wal_writer_flush_after, то WAL записывается только в операционную систему, а не на диск. Если wal_writer_flush_after установлен в 0 то данные WAL всегда сбрасываются немедленно. Если это значение указано без единиц измерения, оно принимается как блоки WAL, то есть байты XLOG_BLCKSZ, обычно 8 КБ. По умолчанию это 1MB. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

commit_delay (integer)

  • Установка commit_delay добавляет задержку перед началом commit_delay WAL. Это может улучшить пропускную способность групповой фиксации, позволяя большему количеству транзакций фиксироваться через один сброс WAL, если загрузка системы достаточно высока, чтобы дополнительные транзакции были готовы к фиксации в течение заданного интервала. Однако это также увеличивает задержку вплоть до commit_delay для каждого commit_delay WAL. Поскольку задержка просто теряется, если никакие другие транзакции не готовы к фиксации, задержка выполняется только в том случае, если по крайней мере commit_siblings другие транзакции активны, когда собирается инициировать сброс. Кроме того, никакие задержки не выполняются, если fsync отключен. Если это значение указано без единиц измерения, оно принимается за микросекунды. По умолчанию commit_delay равен нулю (без задержки). Только суперпользователи могут изменять эту настройку.

  • В QHB первый процесс, который становится готовым к очистке, ожидает установленный интервал, в то время как последующие процессы ждут только до тех пор, пока лидер не завершит операцию очистки.

commit_siblings (integer)

  • Минимальное количество одновременных открытых транзакций, которое требуется для выполнения задержки commit_delay. Большее значение повышает вероятность того, что хотя бы еще одна транзакция будет готова к фиксации в течение интервала задержки. По умолчанию используется пять транзакций.

Checkpoints

checkpoint_timeout (integer)

  • Максимальное время между автоматическими контрольными точками WAL. Если это значение указано без единиц измерения, оно принимается за секунды. Допустимый диапазон составляет от 30 секунд до одного дня. По умолчанию это пять минут (5min минут). Увеличение этого параметра может увеличить время, необходимое для восстановления после сбоя. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

checkpoint_completion_target (с floating point)

  • Определяет цель завершения контрольной точки, как часть общего времени между контрольными точками. По умолчанию это 0,5. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

checkpoint_flush_after (integer)

  • Всякий раз, когда во время выполнения контрольной точки было записано больше этого объема данных, попытайтесь заставить ОС выполнить эти записи в базовое хранилище. Это ограничит количество «грязных» данных в кеше страниц ядра, уменьшая вероятность зависаний при fsync в конце контрольной точки или когда ОС записывает данные большими пакетами в фоновом режиме. Зачастую это приводит к значительному снижению задержки транзакций, но также есть некоторые случаи, особенно с рабочими нагрузками, которые больше, чем shared_buffers, но меньше, чем кеш страниц ОС, где производительность может снизиться. Этот параметр может не повлиять на некоторые платформы. Если это значение указано без единиц измерения, оно принимается как блоки, то есть байты BLCKSZ, обычно 8 КБ. Допустимый диапазон: от 0, что отключает принудительную обратную запись, до 2MB. По умолчанию 256kB в Linux, 0 другом месте. (Если BLCKSZ не равен 8 КБ, значения по умолчанию и максимальные значения масштабируются пропорционально ему). Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

checkpoint_warning (integer)

  • Записать сообщение в журнал сервера, если контрольные точки, вызванные заполнением файлов сегментов WAL, max_wal_size ближе друг к другу, чем это количество времени (что говорит о том, что max_wal_size должен быть повышен). Если это значение указано без единиц измерения, оно принимается за секунды. Значение по умолчанию составляет 30 секунд (30s). Ноль отключает предупреждение. Предупреждения не будут генерироваться, если checkpoint_timeout меньше, чем checkpoint_warning. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

max_wal_size (integer)

  • Максимальный размер, позволяющий WAL расти между автоматическими контрольными точками WAL. Это мягкий предел; Размер WAL может превышать max_wal_size при особых обстоятельствах, таких как большая нагрузка, сбой команды archive_command или высокий параметр wal_keep_segments. Если это значение указано без единиц измерения, оно принимается за мегабайты. По умолчанию это 1 ГБ. Увеличение этого параметра может увеличить время, необходимое для восстановления после сбоя. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

min_wal_size (integer)

  • Пока использование диска WAL остается ниже этого параметра, старые файлы WAL всегда перерабатываются для использования в будущем на контрольной точке, а не удаляются. Это можно использовать для гарантии того, что достаточно места WAL зарезервировано для обработки пиков при использовании WAL, например, при выполнении больших пакетных заданий. Если это значение указано без единиц измерения, оно принимается за мегабайты. По умолчанию установлено 80 МБ. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

Архивирование

archive_mode (enum)

  • Когда archive_mode включен, заполненные сегменты WAL отправляются в архивное хранилище с помощью параметра archive_command. Помимо off, для отключения есть два режима: on и always. Во время нормальной работы нет никакой разницы между этими двумя режимами, но при установке на always архиватор WAL включается также во время восстановления архива или режима ожидания. В always режиме все файлы, восстановленные из архива или переданные с потоковой репликацией, будут заархивированы (снова). Смотрите раздел 26.2.9 для деталей.

  • archive_mode и archive_command являются отдельными переменными, так что archive_command можно изменять, не выходя из режима архивирования. Этот параметр можно установить только при запуске сервера. archive_mode не может быть включен, когда wal_level установлен на minimal.

archive_command (string)

  • Команда локальной оболочки, выполняемая для архивирования завершенного сегмента файла WAL. Любой %p в строке заменяется путем к файлу, который нужно заархивировать, а любой %f заменяется только именем файла. (Путь указывается относительно рабочего каталога сервера, т. %% Каталога данных кластера). Используйте %% для встраивания фактического символа % в команду. Для команды важно возвратить нулевой статус выхода, только если это успешно. Для получения дополнительной информации см. Раздел 25.3.1.

  • Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. Он игнорируется, если archive_mode был включен при запуске сервера. Если archive_command является пустой строкой (по умолчанию), а archive_mode включен, архивация WAL временно отключается, но сервер продолжает накапливать файлы сегментов WAL в ожидании, что в ближайшее время будет предоставлена команда. Задание команды archive_command, которая ничего не делает, но возвращает значение true, например /bin/true (REM в Windows), эффективно отключает архивирование, но также разрывает цепочку файлов WAL, необходимых для восстановления архива, поэтому ее следует использовать только в необычных случаях.

archive_timeout (integer)

  • Команда archive_command вызывается только для завершенных сегментов WAL. Следовательно, если ваш сервер генерирует небольшой трафик WAL (или имеет периоды простоя, когда это происходит), может быть длительная задержка между завершением транзакции и ее безопасной записью в архивном хранилище. Чтобы ограничить возраст неархивированных данных, вы можете установить archive_timeout чтобы сервер периодически переключался на новый файл сегмента WAL. Если этот параметр больше нуля, сервер будет переключаться на новый файл сегмента по истечении этого промежутка времени с момента последнего переключения файла сегмента, и когда-либо было выполнено какое-либо действие с базой данных, включая одну контрольную точку (контрольные точки пропускаются, если есть нет активности базы данных). Обратите внимание, что архивные файлы, которые закрываются рано из-за принудительного переключения, имеют ту же длину, что и полностью заполненные файлы. Следовательно, неразумно использовать очень короткое значение archive_timeout - это приведет к переполнению вашего архивного хранилища. Параметры archive_timeout минуты или около того обычно разумны. Следует рассмотреть возможность использования потоковой репликации вместо архивирования, если вы хотите, чтобы данные копировались с главного сервера быстрее, чем это. Если это значение указано без единиц измерения, оно принимается за секунды. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

Восстановление из архива

В этом разделе описываются параметры, которые применяются только на время восстановления. Они должны быть сброшены для любого последующего восстановления, которое вы хотите выполнить.

«Восстановление» охватывает использование сервера в качестве резервного или для целевого восстановления. Как правило, режим ожидания используется для обеспечения высокой доступности и / или масштабируемости чтения, тогда как целевое восстановление используется для восстановления после потери данных.

Чтобы запустить сервер в режиме ожидания, создайте файл с именем standby.signal в каталоге данных. Сервер войдет в режим восстановления и не остановит восстановление после достижения конца архивированной WAL, но будет продолжать пытаться продолжить восстановление, подключившись к серверу-отправителю, как указано параметром primary_conninfo и / или выбрав новые сегменты WAL с помощью команды restore_command. Для этого режима интерес представляют параметры из этого раздела и раздела Резервные серверы. Параметры из раздела Точки восстановления также будут применяться, но, как правило, бесполезны в этом режиме.

Чтобы запустить сервер в целевом режиме восстановления, создайте файл с именем recovery.signal в каталоге данных. Если созданы файлы standby.signal и recovery.signal, режим ожидания имеет приоритет. Целевой режим восстановления заканчивается, когда архивированная WAL полностью воспроизводится или когда достигается recovery_target. В этом режиме будут использоваться параметры из этого раздела и раздела Точки восстановления.

restore_command (string)

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

  • Для команды важно возвратить нулевой статус выхода, только если это успешно. У команды будут запрошены имена файлов, которых нет в архиве; он должен возвращать ненулевое значение, когда это требуется Пример:

restore_command = 'cp /mnt/server/archivedir/%f "%p"'
  • Исключением является то, что если команда была прервана сигналом (отличным от SIGTERM, который используется как часть отключения сервера базы данных) или ошибкой оболочки (например, команда не найдена), то восстановление будет прервано, и сервер будет не пускай

  • Этот параметр можно установить только при запуске сервера.

archive_cleanup_command (string)

  • Этот необязательный параметр указывает команду оболочки, которая будет выполняться при каждой точке перезапуска. Цель archive_cleanup_command - предоставить механизм для очистки старых заархивированных файлов WAL, которые больше не нужны резервному серверу. Любой %r заменяется именем файла, содержащего последнюю действительную точку перезапуска. Это самый ранний файл, который необходимо сохранить, чтобы обеспечить возможность перезапуска восстановления, и поэтому все файлы ранее, чем %r могут быть безопасно удалены. Эта информация может быть использована для усечения архива до минимума, необходимого для поддержки перезапуска из текущего восстановления. Модуль qhb_archivecleanup часто используется в archive_cleanup_command для конфигураций с одним резервом, например:
archive_cleanup_command = 'qhb-archivecleanup /mnt/server/archivedir %r'
  • Однако обратите внимание, что если несколько резервных серверов восстанавливаются из одного и того же архивного каталога, вам необходимо убедиться, что вы не удаляете файлы WAL, пока они больше не нужны ни одному из серверов. archive_cleanup_command обычно используется в конфигурации с горячим archive_cleanup_command . Напишите %% для вставки фактического символа % в команду.

  • Если команда возвращает ненулевой статус выхода, будет записано сообщение с предупреждением. Исключением является то, что если команда была прервана сигналом или ошибкой оболочки (например, команда не найдена), возникнет фатальная ошибка.

  • Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

recovery_end_command (string)

  • Этот параметр указывает команду оболочки, которая будет выполнена только один раз в конце восстановления. Этот параметр не является обязательным. Цель recovery_end_command - предоставить механизм для очистки после репликации или восстановления. Любой %r заменяется именем файла, содержащего последнюю действительную точку перезапуска, как в archive_cleanup_command.

  • Если команда возвращает ненулевой статус выхода, то будет записано сообщение журнала предупреждений, и база данных все равно продолжит запуск. Исключением является то, что если команда была прервана сигналом или ошибкой со стороны оболочки (например, команда не найдена), база данных не продолжит запуск.

  • Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

Точки восстановления

По умолчанию восстановление будет восстановлено до конца журнала WAL. Следующие параметры могут использоваться для указания более ранней точки остановки. Можно использовать самое большее из recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time или recovery_target_xid; если в файле конфигурации указано более одного из них, возникнет ошибка. Эти параметры могут быть установлены только при запуске сервера.

recovery_target = ’immediate’

  • Этот параметр указывает, что восстановление должно завершиться, как только будет достигнуто согласованное состояние, т. Е. Как можно раньше. При восстановлении из оперативной резервной копии это означает точку, на которой завершилось создание резервной копии.

  • Технически это строковый параметр, но в данный момент допустимым является только значение ’immediate’.

recovery_target_name (string)

  • Этот параметр указывает именованную точку восстановления (созданную с помощью pg_create_restore_point()), к которой будет продолжено восстановление.

recovery_target_time (timestamp)

  • Этот параметр указывает метку времени, до которой будет продолжаться восстановление. Точная точка остановки также зависит от recovery_target_inclusive.

recovery_target_xid (string)

  • Этот параметр указывает идентификатор транзакции, до которой будет продолжаться восстановление. Имейте в виду, что хотя идентификаторы транзакций назначаются последовательно в начале транзакции, транзакции могут выполняться в другом числовом порядке. Будут восстановлены транзакции, совершенные до (и, возможно, включая) указанной транзакции. Точная точка остановки также зависит от recovery_target_inclusive.

recovery_target_lsn (pg_lsn)

  • Этот параметр указывает номер LSN расположения журнала записи с опережением, до которого будет продолжаться восстановление. Точная точка остановки также зависит от recovery_target_inclusive. Этот параметр анализируется с использованием системного типа данных pg_lsn.

Следующие параметры дополнительно определяют цель восстановления и влияют на то, что происходит при достижении цели:

recovery_target_inclusive (boolean)

  • Указывает, следует ли останавливаться сразу после указанной цели восстановления (on) Или непосредственно перед целью восстановления (off). Применяется, когда указаны recovery_target_lsn, recovery_target_time или recovery_target_xid. Этот параметр определяет, будут ли транзакции, имеющие точно целевое местоположение WAL (LSN), время фиксации или идентификатор транзакции, соответственно, включаться в восстановление. По умолчанию включено.

recovery_target_timeline (string)

  • Определяет восстановление в конкретную временную шкалу. Значение может быть числовым идентификатором временной шкалы или специальным значением. current значение восстанавливается по той же временной шкале, которая была текущей, когда была сделана базовая резервная копия. Значение latest восстанавливается до последней временной шкалы, найденной в архиве, что полезно на резервном сервере. latest по умолчанию.

  • Обычно этот параметр нужно устанавливать только в сложных ситуациях повторного восстановления, когда вам необходимо вернуться в состояние, которое само было достигнуто после восстановления на определенный момент времени. См. Раздел 25.3.5 для обсуждения.

recovery_target_action (enum)

  • Указывает, какое действие должен предпринять сервер после достижения цели восстановления. По умолчанию используется pause, что означает, что восстановление будет приостановлено. promote означает, что процесс восстановления завершится, и сервер начнет принимать подключения. Наконец, shutdown остановит сервер после достижения цели восстановления.

  • Предполагаемое использование параметра pause - разрешить выполнение запросов к базе данных, чтобы проверить, является ли эта цель восстановления наиболее желательной точкой для восстановления. Приостановленное состояние может быть восстановлено с помощью pg_wal_replay_resume() (см. Таблицу III.8.86), которая затем приводит к завершению восстановления. Если эта цель восстановления не является желаемой точкой остановки, затем выключите сервер, измените настройки цели восстановления на более позднюю цель и перезапустите, чтобы продолжить восстановление.

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

  • Обратите внимание, что поскольку recovery.signal не будет удален, если для recovery_target_action задано значение shutdown, любой последующий запуск будет завершен немедленным завершением работы, если не будет изменена конфигурация или файл recovery.signal будет удален вручную.

  • Этот параметр не действует, если цель восстановления не установлена. Если hot_standby не включен, настройка pause будет действовать так же, как shutdown.

Копирование

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

Передающий сервер

Эти параметры могут быть установлены на любом сервере, который должен отправлять данные репликации на один или несколько резервных серверов. Мастер всегда является передающим сервером, поэтому эти параметры всегда должны быть установлены на мастере. Роль и значение этих параметров не изменяются после того, как резерв становится главным.

max_wal_senders (integer)

  • Задает максимальное количество одновременных подключений с резервных серверов или клиентов потокового резервного копирования (т. Е. Максимальное количество одновременно работающих процессов отправителя WAL). По умолчанию 10. Значение 0 означает, что репликация отключена. При резком отключении потокового клиента оставшийся слот подключения может остаться позади до истечения времени ожидания, поэтому этот параметр следует установить немного выше, чем максимальное число ожидаемых клиентов, чтобы отключенные клиенты могли немедленно восстановить соединение. Этот параметр можно установить только при запуске сервера. Кроме того, wal_level должен иметь значение replica или выше, чтобы разрешить подключения с резервных серверов.

  • При запуске резервного сервера вы должны установить для этого параметра то же или более высокое значение, чем на главном сервере. В противном случае запросы не будут разрешены на резервном сервере.

max_replication_slots (integer)

  • Задает максимальное количество слотов репликации , которое может поддерживать сервер. По умолчанию установлено значение 10. Этот параметр можно установить только при запуске сервера. Если установить значение, меньшее, чем количество существующих в настоящее время слотов репликации, сервер не запустится. Кроме того, wal_level должен быть установлен на replica или выше, чтобы можно было использовать слоты репликации.

wal_keep_segments (integer)

  • Задает минимальное количество прошлых сегментов файла журнала, хранящихся в каталоге pg_wal, в случае, если резервному серверу необходимо извлечь их для потоковой репликации. Каждый сегмент обычно составляет 16 мегабайт. Если резервный сервер, подключенный к отправляющему серверу, отстает более чем на сегменты wal_keep_segments, отправляющий сервер может удалить сегмент WAL, все еще необходимый резервному, и в этом случае подключение репликации будет прервано. В результате нисходящие соединения также в конечном итоге потерпят неудачу. (Однако резервный сервер может восстановиться путем извлечения сегмента из архива, если используется архивация WAL).

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

wal_init_zero (boolean)

  • Если установлено значение on (по умолчанию), эта опция заставляет новые файлы WAL заполняться нулями. В некоторых файловых системах это обеспечивает выделение места перед тем, как нам нужно будет писать записи WAL. Однако файловые системы Copy-On-Write (COW) могут не воспользоваться этой методикой, поэтому предоставляется возможность пропустить ненужную работу. Если установлено значение off, при создании файла записывается только последний байт, так что он имеет ожидаемый размер.

wal_recycle (boolean)

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

wal_sender_timeout (integer)

  • Завершите соединения репликации, которые неактивны дольше, чем это количество времени. Это полезно для отправляющего сервера для обнаружения аварийного сбоя или отключения сети. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Значение по умолчанию составляет 60 секунд. Нулевое значение отключает механизм тайм-аута.

  • С кластером, распределенным по нескольким географическим местоположениям, использование различных значений для местоположения обеспечивает большую гибкость в управлении кластером. Меньшее значение полезно для более быстрого обнаружения сбоев в режиме ожидания с сетевым подключением с низкой задержкой, а большее значение помогает лучше оценить работоспособность режима ожидания, если он находится в удаленном месте, с сетевым подключением с высокой задержкой.

track_commit_timestamp (boolean)

  • Запись времени фиксации транзакций. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. Значение по умолчанию off.

Мастер сервер

Эти параметры могут быть установлены на главном / основном сервере, который должен отправлять данные репликации на один или несколько резервных серверов. Обратите внимание, что в дополнение к этим параметрам wal_level должен быть соответствующим образом установлен на главном сервере, и при желании также может быть включена архивация WAL (см. раздел Архивирование). Значения этих параметров на резервных серверах не имеют значения, хотя вы можете установить их там, чтобы подготовиться к тому, чтобы резервный сервер стал главным.

synchronous_standby_names (string)

  • Задает список резервных серверов, которые могут поддерживать синхронную репликацию, как описано в разделе 26.2.8. Будет один или несколько активных синхронных резервных серверов; транзакции, ожидающие принятия, будут разрешены после того, как эти резервные серверы подтвердят получение своих данных. Синхронными резервными копиями будут те, чьи имена появляются в этом списке, и которые в настоящее время подключены и передают данные в режиме реального времени (как показано состоянием streaming в представлении pg_stat_replication ). Указание более одного синхронного режима ожидания может обеспечить очень высокую доступность и защиту от потери данных.

  • Имя резервного сервера для этой цели является параметром application_name для резервного, как установлено в информации о подключении резервного. В случае ожидания физической репликации это должно быть установлено в параметре primary_conninfo ; по умолчанию используется настройка cluster_name, если установлено, иначе walreceiver. Для логической репликации это может быть установлено в информации о соединении подписки, и по умолчанию это имя подписки. Для других потребителей потока репликации обратитесь к их документации.

  • Этот параметр указывает список резервных серверов, используя любой из следующих синтаксисов:

[FIRST] num_sync ( standby_name [, ...] )
ANY num_sync ( standby_name [, ...] )
standby_name [, ...]
  • где num_sync - это количество синхронных резервных серверов, от которых транзакции должны ждать ответов, а standby_name - это имя резервного сервера. FIRST и ANY указывают способ выбора синхронных резервных серверов из перечисленных серверов.

  • Ключевое слово FIRST сочетании с num_sync задает синхронную репликацию на основе приоритетов и заставляет коммиты транзакций ждать, пока их записи WAL реплицируются в синхронные резервные копии num_sync, выбранные на основе их приоритетов. Например, установка FIRST 3 (s1, s2, s3, s4) заставит каждый коммит ожидать ответов от трех резервных серверов с более высоким приоритетом, выбранных из резервных серверов s1, s2, s3 и s4. Резервные устройства, имена которых появляются ранее в списке, имеют более высокий приоритет и будут рассматриваться как синхронные. Другие резервные серверы, появившиеся позже в этом списке, представляют потенциальные синхронные резервы. Если какой-либо из текущих синхронных резервных серверов отключится по какой-либо причине, он будет немедленно заменен следующим резервным сервером с наивысшим приоритетом. Ключевое слово FIRST является необязательным.

  • Ключевое слово ANY сочетании с num_sync задает синхронную репликацию на основе кворума и заставляет коммиты транзакций ждать, пока их записи WAL будут реплицированы, по крайней мере, в список standbys, указанный в num_sync. Например, установка ANY 3 (s1, s2, s3, s4) заставит каждую фиксацию продолжаться, как только ответят по крайней мере любые три резервных элемента s1, s2, s3 и s4.

  • FIRST и ANY нечувствительны к регистру. Если эти ключевые слова используются в качестве имени резервного сервера, его имя в режиме ожидания должно быть заключено в двойные кавычки.

  • Третий синтаксис поддерживается в QHB. Это так же, как первый синтаксис с FIRST и num_sync равными 1. Например, FIRST 1 (s1, s2) и s1, s2 имеют то же значение: либо s1 либо s2 выбран в качестве синхронного режима ожидания.

  • Специальная запись * соответствует любому резервному имени.

  • Не существует механизма для обеспечения уникальности резервных имен. В случае дубликатов один из подходящих резервных копий будет рассматриваться как более высокий приоритет, хотя какой именно является неопределенным.

Заметка
Каждое имя standby_name должно иметь форму действительного идентификатора SQL, если это не *. При необходимости вы можете использовать двойные кавычки. Но обратите внимание, что имена в режиме ожидания сравниваются с именами приложений в режиме ожидания без учета регистра, в двойных кавычках или нет.

  • Если здесь не указаны синхронные резервные имена, синхронная репликация не включена и транзакции не будут ждать репликации. Это конфигурация по умолчанию. Даже когда синхронная репликация включена, отдельные транзакции можно настроить так, чтобы они не ожидали репликации, установив для параметра synchronous_commit значение local или off.

  • Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

vacuum_defer_cleanup_age (integer)

  • Определяет количество транзакций, на которые обновления VACUUM и HOT будут откладывать очистку версий мертвых строк. По умолчанию транзакции равны нулю, это означает, что версии мертвых строк могут быть удалены как можно скорее, то есть, как только они больше не видны для любой открытой транзакции. Вы можете установить ненулевое значение на основном сервере, который поддерживает серверы горячего резервирования, как описано в разделе 26.5. Это дает больше времени для выполнения запросов в режиме ожидания без возникновения конфликтов из-за ранней очистки строк. Тем не менее, поскольку значение измеряется с точки зрения количества транзакций записи, происходящих на первичном сервере, трудно предсказать, сколько дополнительного времени будет предоставлено для резервных запросов. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

  • Вам также следует рассмотреть возможность установки hot_standby_feedback на резервных серверах в качестве альтернативы использованию этого параметра.

  • Это не предотвращает очистку мертвых строк, которые достигли возраста, указанного в old_snapshot_threshold.

Резервные серверы

Эти параметры управляют поведением резервного сервера, который должен получать данные репликации. Их значения на главном сервере не имеют значения.

primary_conninfo (string)

  • Задает строку подключения, которая будет использоваться резервным сервером для соединения с отправляющим сервером. Если переменная окружения также не установлена, то используются значения по умолчанию.

  • Строка подключения должна указывать имя хоста (или адрес) отправляющего сервера, а также номер порта, если он не совпадает со значением резервного сервера по умолчанию. Также укажите имя пользователя, соответствующее роли с соответствующей привилегией на отправляющем сервере . Пароль также необходимо указать, если отправитель требует аутентификации по паролю. Его можно указать в строке primary_conninfo или в отдельном файле ~/.pgpass на резервном сервере (используйте replication качестве имени базы данных). Не указывайте имя базы данных в строке primary_conninfo.

  • Этот параметр можно установить только при запуске сервера. Этот параметр не действует, если сервер не находится в режиме ожидания.

primary_slot_name (string)

  • Опционально указывает существующий слот репликации, который будет использоваться при подключении к отправляющему серверу посредством потоковой репликации для управления удалением ресурсов на вышестоящем узле . Этот параметр можно установить только при запуске сервера. Этот параметр не имеет эффекта, если primary_conninfo не установлен.

promote_trigger_file (string)

  • Указывает файл триггера, присутствие которого завершает восстановление в режиме ожидания. Даже если это значение не установлено, вы все равно можете продвинуть режим ожидания с помощью qhb_ctl promote или вызова pg_promote. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

hot_standby (boolean)

  • Указывает, можете ли вы подключаться и выполнять запросы во время восстановления, как описано в разделе 26.5. Значение по умолчанию включено. Этот параметр можно установить только при запуске сервера. Это действует только во время восстановления архива или в режиме ожидания.

max_standby_archive_delay (integer)

  • Когда активен горячий резерв, этот параметр определяет, как долго резервный сервер должен ждать, прежде чем отменять резервные запросы, конфликтующие с записями WAL, подлежащими применению. max_standby_archive_delay применяется, когда данные WAL читаются из архива WAL (и, следовательно, не являются текущими). Если это значение указано без единиц измерения, оно принимается за миллисекунды. По умолчанию 30 секунд. Значение -1 позволяет ждущему клиенту бесконечно ждать завершения конфликтующих запросов. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

  • Обратите внимание, что max_standby_archive_delay отличается от максимальной продолжительности времени, в течение которого запрос может выполняться до отмены; скорее это максимальное общее время, разрешенное для применения данных одного сегмента WAL. Таким образом, если один запрос привел к значительной задержке ранее в сегменте WAL, последующие конфликтующие запросы будут иметь гораздо меньше льготного времени.

max_standby_streaming_delay (integer)

  • Когда активен горячий резерв, этот параметр определяет, как долго резервный сервер должен ждать, прежде чем отменять резервные запросы, конфликтующие с записями WAL, подлежащими применению. max_standby_streaming_delay применяется, когда данные WAL принимаются посредством потоковой репликации. Если это значение указано без единиц измерения, оно принимается за миллисекунды. По умолчанию 30 секунд. Значение -1 позволяет ждущему клиенту бесконечно ждать завершения конфликтующих запросов. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

  • Обратите внимание, что max_standby_streaming_delay отличается от максимальной продолжительности времени, в течение которого запрос может выполняться до отмены; скорее это максимальное общее время, разрешенное для применения данных WAL после их получения от основного сервера. Таким образом, если один запрос привел к значительной задержке, последующие конфликтующие запросы будут иметь гораздо меньше льготного времени до тех пор, пока резервный сервер не перехватит снова.

wal_receiver_status_interval (integer)

  • Задает минимальную частоту для процесса приемника WAL в режиме ожидания для отправки информации о ходе репликации в основной или восходящий режим ожидания, где это можно увидеть с помощью представления pg_stat_replication. Резервный сервер сообщит о последнем записанном в журнал месте записи с опережением записи, о последней позиции, которую он записал на диск, и о последней позиции, которую он применил. Значение этого параметра - максимальное время между отчетами. Обновления отправляются каждый раз, когда меняются позиции записи или очистки, или, по крайней мере, так часто, как указано в этом параметре. Таким образом, позиция применения может немного отставать от истинной позиции. Если это значение указано без единиц измерения, оно принимается за секунды. Значение по умолчанию составляет 10 секунд. Установка этого параметра в ноль полностью отключает обновления статуса. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

hot_standby_feedback (boolean)

  • Указывает, будет ли горячий резерв отправлять отзывы первичному или восходящему резерву о запросах, выполняющихся в данный момент в резерве. Этот параметр можно использовать для устранения отмен запросов, вызванных записями очистки, но может вызвать переполнение базы данных на первичном сервере для некоторых рабочих нагрузок. Сообщения обратной связи не будут отправляться чаще, чем один раз за wal_receiver_status_interval. Значение по умолчанию off. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

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

  • Этот параметр не переопределяет поведение old_snapshot_threshold на первичном сервере; моментальный снимок в режиме ожидания, который превышает возрастной порог основного устройства, может стать недействительным, что приведет к отмене транзакций в режиме ожидания. Это связано с тем, что old_snapshot_threshold предназначен для предоставления абсолютного предела времени, в течение которого мертвые строки могут способствовать раздуванию, что в противном случае было бы нарушено из-за конфигурации режима ожидания.

wal_receiver_timeout (integer)

  • Завершите соединения репликации, которые неактивны дольше, чем это количество времени. Это полезно для принимающего резервного сервера, чтобы обнаружить сбой первичного узла или отключение сети. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Значение по умолчанию составляет 60 секунд. Нулевое значение отключает механизм тайм-аута. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

wal_retrieve_retry_interval (integer)

  • Указывает, как долго резервный сервер должен ждать, когда данные WAL недоступны из каких-либо источников (потоковая репликация, локальный pg_wal или архив WAL), прежде чем пытаться снова получить данные WAL. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Значение по умолчанию составляет 5 секунд. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

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

recovery_min_apply_delay (integer)

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

  • Возможно, что задержка репликации между серверами превышает значение этого параметра, и в этом случае задержка не добавляется. Обратите внимание, что задержка рассчитывается между отметкой времени WAL, записанной на главном устройстве, и текущим временем в режиме ожидания. Задержки передачи из-за задержек в сети или каскадных конфигураций репликации могут значительно сократить фактическое время ожидания. Если системные часы на главном и в режиме ожидания не синхронизированы, это может привести к восстановлению, применяя записи раньше, чем ожидалось; но это не главная проблема, потому что полезные настройки этого параметра намного больше, чем типичные временные отклонения между серверами.

  • Задержка происходит только в записях WAL для фиксации транзакции. Другие записи воспроизводятся как можно быстрее, что не является проблемой, поскольку правила видимости MVCC гарантируют, что их эффекты не видны до тех пор, пока не будет применена соответствующая запись фиксации.

  • Задержка наступает, когда база данных в процессе восстановления достигает согласованного состояния, пока резервный ресурс не будет повышен или запущен. После этого восстановление завершится без ожидания.

  • Этот параметр предназначен для использования с развертываниями потоковой репликации; однако, если указан параметр, он будет учитываться во всех случаях, кроме восстановления после сбоя. hot_standby_feedback будет задержан использованием этой функции, которая может привести к раздутию на мастер; используйте оба вместе с осторожностью.

!!! Предупреждение

Этот параметр затрагивает синхронную репликацию, когда для synchronous_commit задано значение remote_apply ; каждый COMMIT должен ждать, пока его не применят.

  • Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

Подписчики

Эти параметры управляют поведением подписчика логической репликации. Их значения для издателя не имеют значения.

Обратите внимание, что параметры конфигурации wal_receiver_timeout, wal_receiver_status_interval и wal_retrieve_retry_interval влияют на потоки логической репликации.

max_logical_replication_workers (int)

  • Задает максимальное количество потоков логической репликации. Это включает в себя как прикладные потоки, так и потоки синхронизации таблиц.

  • Потоки логической репликации берутся из пула, определенного max_worker_processes.

  • Значение по умолчанию 4.

max_sync_workers_per_subscription (integer)

  • Максимальное количество потоков синхронизации на подписку. Этот параметр управляет степенью параллелизма исходной копии данных во время инициализации подписки или при добавлении новых таблиц.

  • В настоящее время в таблице может быть только один поток синхронизации.

  • Рабочие синхронизации взяты из пула, определенного max_logical_replication_workers.

  • Значением по умолчанию является 2.

Планирование запросов

Конфигурация метода планирования

Эти параметры конфигурации предоставляют грубый метод воздействия на планы запросов, выбранные оптимизатором запросов. Если план по умолчанию, выбранный оптимизатором для определенного запроса, не является оптимальным, временное решение состоит в том, чтобы использовать один из этих параметров конфигурации, чтобы заставить оптимизатор выбрать другой план. Улучшенные способы улучшения качества планов, выбранного оптимизатор включают корректировки констант затрат планировщика (см раздел Константы стоимости планировщика), работают ANALYZE вручную, увеличивая значение default_statistics_target параметра конфигурации, а также увеличение количества статистических данных, собранное для отдельных столбцов используя ALTER TABLE SET STATISTICS.

enable_bitmapscan (boolean)

Включает или отключает использование планировщиком запросов типов планов растрового сканирования. По умолчанию включено.

enable_gathermerge (boolean)

Включает или отключает использование планировщиком запросов типов планов слияния. По умолчанию включено.

enable_hashagg (boolean)

Включает или отключает использование планировщиком запросов типов плана хэширования. По умолчанию включено.

enable_hashjoin (boolean)

Включает или отключает использование планировщиком запросов типов планов хэш-соединения. По умолчанию включено.

enable_indexscan (boolean)

Включает или отключает использование планировщиком запросов типов планов сканирования индекса. По умолчанию включено.

enable_indexonlyscan (boolean)

Включает или отключает использование планировщиком запросов типов планов проверки только для индекса (см. раздел Сканирование только по индексу и покрывающие индексы). По умолчанию включено.

enable_material (boolean)

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

enable_mergejoin (boolean)

Включает или отключает использование планировщиком запросов типов планов слиянием и объединением. По умолчанию включено.

enable_nestloop (boolean)

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

enable_parallel_append (boolean)

Включает или отключает использование планировщиком запросов типов планов добавления с параллельной поддержкой. По умолчанию включено.

enable_parallel_hash (boolean)

Включает или отключает использование в планировщике запросов типов планов хеш-соединения с параллельным хешем. Не имеет эффекта, если планы хеш-соединения также не включены. По умолчанию включено.

enable_partition_pruning (boolean)

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

enable_partitionwise_join (boolean)

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

enable_partitionwise_aggregate (boolean)

Включает или отключает использование планировщиком запросов групповой группировки или агрегации по секциям, что позволяет группировать или агрегировать по секционированным таблицам, выполняемым отдельно для каждой секции. Если предложение GROUP BY не включает ключи разделов, только частичное агрегирование может быть выполнено для каждого раздела, а финализация должна быть выполнена позже. Поскольку группировка или агрегация по частям могут использовать значительно больше процессорного времени и памяти во время планирования, по умолчанию off.

enable_seqscan (boolean)

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

enable_sort (boolean)

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

enable_tidscan (boolean)

Включает или отключает использование планировщиком запросов типов планов сканирования TID. По умолчанию включено.

Константы стоимости планировщика

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

Заметка
К сожалению, нет четко определенного метода определения идеальных значений для переменных стоимости. Их лучше всего рассматривать как средние значения для всего набора запросов, которые получит конкретная установка. Это означает, что менять их на основании всего лишь нескольких экспериментов очень рискованно.

seq_page_cost (с floating point)

  • Устанавливает оценку планировщика стоимости выборки страницы на диске, которая является частью серии последовательных выборок. По умолчанию это 1.0. Это значение можно переопределить для таблиц и индексов в определенном табличном пространстве, установив параметр табличного пространства с тем же именем (см.ALTER TABLESPACE).

random_page_cost (с floating point)

  • Устанавливает оценку планировщика стоимости непоследовательной выборки страницы диска. По умолчанию это 4.0. Это значение можно переопределить для таблиц и индексов в определенном табличном пространстве, установив параметр табличного пространства с тем же именем (см. ALTER TABLESPACE).

  • Уменьшение этого значения относительно seq_page_cost приведет к тому, что система предпочтет сканирование индекса; его увеличение сделает просмотр индекса относительно более дорогим. Вы можете увеличить или уменьшить оба значения вместе, чтобы изменить важность затрат на дисковый ввод-вывод относительно затрат на ЦП, которые описываются следующими параметрами.

  • Произвольный доступ к механическому дисковому хранилищу обычно намного дороже, чем четырехкратный последовательный доступ. Однако используется более низкий уровень по умолчанию (4.0), поскольку предполагается, что большинство случайных обращений к диску, таких как индексированные операции чтения, находятся в кеше. Значение по умолчанию можно рассматривать как моделирование произвольного доступа как в 40 раз медленнее, чем последовательное, при этом ожидается, что 90% случайных чтений будут кэшироваться.

  • Если вы считаете, что кэш-память в 90% является неверным допущением для вашей рабочей нагрузки, вы можете увеличить random_page_cost, чтобы лучше отражать истинную стоимость случайного чтения из хранилища. Соответственно, если ваши данные, вероятно, будут полностью в кеше, например, когда база данных меньше общей памяти сервера, может быть целесообразно уменьшение random_page_cost. Хранилище с низкой стоимостью случайного чтения относительно последовательных, например, твердотельных накопителей, также может быть лучше смоделировано с более низким значением random_page_cost.

Заметка
Хотя система позволит вам установить random_page_cost меньше, чем seq_page_cost, это физически seq_page_cost. Однако установка их равными имеет смысл, если база данных полностью кэшируется в ОЗУ, поскольку в этом случае штраф за несоответствие страниц не взимается. Кроме того, в сильно кэшированной базе данных вы должны снизить оба значения относительно параметров ЦП, поскольку стоимость извлечения страницы уже в ОЗУ намного меньше, чем обычно.

cpu_tuple_cost (с floating point)

  • Устанавливает плановую оценку стоимости обработки каждой строки во время запроса. По умолчанию это 0,01.

cpu_index_tuple_cost (с floating point)

  • Устанавливает плановую оценку стоимости обработки каждой записи индекса во время сканирования индекса. По умолчанию это 0,005.

cpu_operator_cost (с floating point)

  • Устанавливает плановую оценку стоимости обработки каждого оператора или функции, выполняемой во время запроса. По умолчанию это 0,0025.

parallel_setup_cost (с floating point)

  • Устанавливает плановую оценку стоимости запуска параллельных рабочих процессов. По умолчанию это 1000.

parallel_tuple_cost (с floating point)

  • Устанавливает плановую оценку стоимости переноса одного кортежа из параллельного рабочего процесса в другой процесс. По умолчанию это 0,1.

min_parallel_table_scan_size (integer)

  • Устанавливает минимальный объем табличных данных, которые необходимо сканировать, чтобы можно было рассмотреть параллельное сканирование. При параллельном последовательном сканировании количество проверенных данных таблицы всегда равно размеру таблицы, но при использовании индексов количество проверенных данных таблицы обычно будет меньше. Если это значение указано без единиц измерения, оно принимается как блоки, то есть байты BLCKSZ, обычно 8 КБ. По умолчанию используется 8 мегабайт (8 МБ).

min_parallel_index_scan_size (integer)

  • Устанавливает минимальный объем индексных данных, которые должны быть отсканированы, чтобы можно было рассмотреть параллельное сканирование. Обратите внимание, что параллельное сканирование индекса обычно не затрагивает весь индекс; это число страниц, которое, по мнению плановика, будет действительно затронуто сканированием. Если это значение указано без единиц измерения, оно принимается как блоки, то есть байты BLCKSZ, обычно 8 КБ. По умолчанию используется 512 килобайт (512kB).

effective_cache_size (integer)

  • Устанавливает предположение планировщика об эффективном размере дискового кэша, доступного для одного запроса. Это учитывается при оценке стоимости использования индекса; чем выше значение, тем выше вероятность того, что будет использоваться индексное сканирование, чем ниже значение, тем больше вероятность того, что будет использовано последовательное сканирование. При установке этого параметра вы должны учитывать как общие буферы QHB, так и часть дискового кэша ядра, которая будет использоваться для файлов данных QHB, хотя некоторые данные могут существовать в обоих местах. Также учитывайте ожидаемое количество одновременных запросов к разным таблицам, так как им придется совместно использовать доступное пространство. Этот параметр не влияет на размер разделяемой памяти, выделяемой QHB, а также не резервирует кэш-память ядра; он используется только для целей оценки. Система также не предполагает, что данные остаются в кеше диска между запросами. Если это значение указано без единиц измерения, оно принимается как блоки, то есть байты BLCKSZ, обычно 8 КБ. По умолчанию используется 4 гигабайта (4GB). (Если BLCKSZ не равен 8 КБ, значение по умолчанию масштабируется пропорционально ему).

jit_above_cost (с floating point)

  • Задает стоимость запроса, выше которой активируется JIT-компиляция, если она включена . Выполнение JIT стоит времени планирования, но может ускорить выполнение запроса. Установка этого параметра в -1 отключает компиляцию JIT. По умолчанию это 100000.

jit_inline_above_cost (с floating point)

  • Устанавливает стоимость запроса, выше которой JIT-компиляция пытается встроить функции и операторы. Встраивание добавляет время планирования, но может улучшить скорость выполнения. Не имеет смысла устанавливать это значение меньше, чем jit_above_cost. Установка этого в -1 отключает встраивание. По умолчанию это 500000.

jit_optimize_above_cost (с floating point)

  • Устанавливает стоимость запроса, выше которой JIT-компиляция применяет дорогостоящие оптимизации. Такая оптимизация добавляет время планирования, но может улучшить скорость выполнения. Не имеет смысла устанавливать это значение меньше, чем jit_above_cost, и вряд ли будет полезно установить его больше, чем jit_inline_above_cost. Установка этого значения в -1 отключает дорогостоящие оптимизации. По умолчанию это 500000.

Генетический оптимизатор запросов

Оптимизатор генетических запросов (GEQO) - это алгоритм, который выполняет планирование запросов с использованием эвристического поиска. Это сокращает время планирования сложных запросов (тех, которые объединяют многие отношения) за счет создания планов, которые иногда уступают тем, которые обнаруживаются обычным алгоритмом исчерпывающего поиска. Для получения дополнительной информации см. Главу 59.

geqo (boolean)

  • Включает или отключает генетическую оптимизацию запросов. Это включено по умолчанию. Обычно лучше не выключать его в производстве; переменная geqo_threshold обеспечивает более детальный контроль над GEQO.

geqo_threshold (integer)

  • Используйте генетическую оптимизацию запросов для планирования запросов, по крайней мере, с таким количеством элементов FROM. (Обратите внимание, что конструкция FULL OUTER JOIN считается только одним элементом FROM ). По умолчанию используется значение 12. Для более простых запросов обычно лучше использовать обычный планировщик исчерпывающего поиска, но для запросов со многими таблицами исчерпывающий поиск занимает слишком много времени., часто дольше, чем штраф за выполнение неоптимального плана. Таким образом, пороговое значение размера запроса является удобным способом управления использованием GEQO.

geqo_effort (integer)

  • Управляет компромиссом между временем планирования и качеством плана запроса в GEQO. Эта переменная должна быть целым числом в диапазоне от 1 до 10. Значением по умолчанию является пять. Большие значения увеличивают время, затрачиваемое на планирование запросов, но также повышают вероятность выбора эффективного плана запросов.

  • geqo_effort самом деле ничего не делает напрямую; он используется только для вычисления значений по умолчанию для других переменных, которые влияют на поведение GEQO (описано ниже). Если вы предпочитаете, вы можете установить другие параметры вручную.

geqo_pool_size (integer)

  • Контролирует размер пула, используемого GEQO, то есть количество особей в генетической популяции. Оно должно быть не менее двух, а полезные значения обычно составляют от 100 до 1000. Если оно установлено на ноль (настройка по умолчанию), то подходящее значение выбирается на основе geqo_effort и количества таблиц в запросе.

geqo_generations (integer)

  • Управляет количеством поколений, используемых GEQO, то есть количеством итераций алгоритма. Должно быть хотя бы одно, а полезные значения находятся в том же диапазоне, что и размер пула. Если он установлен на ноль (настройка по умолчанию), то подходящее значение выбирается на основе geqo_pool_size.

geqo_selection_bias (с floating point)

  • Управляет смещением выбора, используемым GEQO. Смещение выбора - это избирательное давление в популяции. Значения могут быть от 1,50 до 2,00; последний по умолчанию.

geqo_seed (с floating point)

  • Управляет начальным значением генератора случайных чисел, используемого GEQO для выбора случайных путей в пространстве поиска порядка соединения. Значение может варьироваться от нуля (по умолчанию) до единицы. Изменение значения изменяет набор исследуемых путей соединения и может привести к тому, что будет найден лучший или худший лучший путь.

Другие варианты планировщика

default_statistics_target (integer)

  • Устанавливает целевой показатель статистики по умолчанию для столбцов таблицы без определенного для столбца целевого значения через ALTER TABLE SET STATISTICS. Большие значения увеличивают время, необходимое для ANALYZE, но могут улучшить качество оценок планировщика. По умолчанию установлено значение 100. Для получения дополнительной информации об использовании статистики планировщиком запросов QHB см. раздел Статистика, используемая планировщиком.

constraint_exclusion (enum)

  • Управляет использованием в планировщике запросов ограничений таблиц для оптимизации запросов. Допустимые значения constraint_exclusion : включено (проверить ограничения для всех таблиц), off (никогда не проверять ограничения) и partition (изучить ограничения только для дочерних таблиц наследования и подзапросов UNION ALL ). partition является настройкой по умолчанию. Он часто используется с традиционными деревьями наследования для улучшения производительности.

  • Когда этот параметр разрешает его для конкретной таблицы, планировщик сравнивает условия запроса с ограничениями таблицы CHECK и пропускает таблицы сканирования, для которых условия противоречат ограничениям. Например:

CREATE TABLE parent(key integer, ...);
CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent);
CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent);
...
SELECT * FROM parent WHERE key = 2400;
  • С включенным исключением ограничений этот SELECT не будет сканировать child1000 вообще, улучшая производительность.

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

  • Обратитесь к разделу Партиционирование и исключение ограничений для получения дополнительной информации об использовании исключения ограничений для реализации разделения.

cursor_tuple_fraction (с floating point)

  • Устанавливает оценку планировщика доли строк курсора, которые будут получены. По умолчанию это 0,1. Меньшие значения этого параметра смещают планировщик в сторону использования планов «быстрого запуска» для курсоров, которые будут быстро извлекать первые несколько строк, и, возможно, потребуется много времени для извлечения всех строк. Большие значения делают больший акцент на общее расчетное время. При максимальном значении 1,0 курсоры планируются точно так же, как и обычные запросы, с учетом только общего расчетного времени, а не того, как скоро могут быть доставлены первые строки.

from_collapse_limit (integer)

  • Планировщик объединит подзапросы в верхние запросы, если итоговый список FROM будет содержать не более этого количества элементов. Меньшие значения сокращают время планирования, но могут привести к ухудшению планов запросов. По умолчанию установлено восемь. Для получения дополнительной информации см. раздел Управление планировщиком с помощью явных предложений JOIN.

  • Установка этого значения в geqo_threshold или более может инициировать использование планировщика GEQO, что приведет к неоптимальным планам. См. раздел Генетический оптимизатор запросов.

jit (boolean)

  • Определяет, может ли компиляция JIT использоваться QHB, если она доступна . По умолчанию включено.

join_collapse_limit (integer)

  • Планировщик переписывает явные конструкции JOIN (кроме FULL JOIN) в списки элементов FROM всякий раз, когда получается список, содержащий не более этого количества элементов. Меньшие значения сокращают время планирования, но могут привести к ухудшению планов запросов.

  • По умолчанию эта переменная установлена так же, как from_collapse_limit, что подходит для большинства применений. Установка его в 1 предотвращает любое изменение порядка явных JOIN. Таким образом, явный порядок соединения, указанный в запросе, будет фактическим порядком, в котором соединяются отношения. Поскольку планировщик запросов не всегда выбирает оптимальный порядок соединения, опытные пользователи могут временно выбрать для этой переменной значение 1, а затем явно указать желаемый порядок соединения. Для получения дополнительной информации см. раздел Управление планировщиком с помощью явных предложений JOIN.

  • Установка этого значения в geqo_threshold или более может инициировать использование планировщика GEQO, что приведет к неоптимальным планам. См. раздел Генетический оптимизатор запросов.

parallel_leader_participation (boolean)

  • Позволяет процессу-руководителю выполнять план запроса в узлах Gather и Gather Merge вместо ожидания рабочих процессов. По умолчанию включено. Если для этого значения установлено значение off вероятность того, что потоки будут заблокированы, снижает вероятность того, что лидер не достаточно быстро читает кортежи, но требует, чтобы процесс лидера ожидал запуска рабочих процессов, прежде чем будут созданы первые кортежи. Степень, в которой лидер может помочь или снизить производительность, зависит от типа плана, количества потоков и продолжительности запроса.

force_parallel_mode (enum)

  • Позволяет использовать параллельные запросы для целей тестирования даже в тех случаях, когда повышение производительности не ожидается. Допустимые значения force_parallel_mode off (использовать параллельный режим только тогда, когда ожидается повышение производительности), on (принудительный параллельный запрос для всех запросов, для которых он считается безопасным), и regress (например, on, но с дополнительными изменениями поведения как объяснено ниже).

  • Более конкретно, установка этого значения on добавит Gather узел в верхней части любого плана запроса, для которых это является безопасным, так что выполняется запрос внутри параллельного рабочего. Даже если параллельный поток недоступен или не может использоваться, такие операции, как запуск субтранзакции, которая будет запрещена в контексте параллельного запроса, будут запрещены, если только планировщик не считает, что это приведет к сбою запроса. Если при установке этого параметра возникают сбои или неожиданные результаты, возможно, некоторые функции, используемые запросом, должны быть помечены как PARALLEL UNSAFE (или, возможно, PARALLEL RESTRICTED ).

  • Установка этого значения для regress имеет все те же эффекты, что и его on плюс некоторые дополнительные эффекты, предназначенные для облегчения автоматического регрессионного тестирования. Обычно сообщения от параллельного потока включают в себя строку контекста, указывающую на это, но настройка regress подавляет эту строку, так что выходные данные такие же, как при непараллельном выполнении. Кроме того, узлы Gather добавленные в планы с помощью этого параметра, скрыты в выводе EXPLAIN поэтому выходные данные соответствуют тому, что было бы получено, если этот параметр был off.

plan_cache_mode (enum)

  • Подготовленные операторы (явно подготовленные или неявно сгенерированные, например, PL / pgSQL) могут быть выполнены с использованием пользовательских или общих планов. Пользовательские планы создаются заново для каждого выполнения с использованием его определенного набора значений параметров, в то время как общие планы не зависят от значений параметров и могут быть повторно использованы при выполнении. Таким образом, использование общего плана экономит время планирования, но если идеальный план сильно зависит от значений параметров, то общий план может быть неэффективным. Выбор между этими параметрами обычно выполняется автоматически, но его можно переопределить с помощью plan_cache_mode. Допустимые значения: auto (по умолчанию), force_custom_plan и force_generic_plan. Этот параметр учитывается при выполнении кэшированного плана, а не при его подготовке. Для получения дополнительной информации см. PREPARE.

Отчеты об ошибках и ведение журнала

Расположение журнала

log_destination (string)

  • QHB поддерживает несколько методов регистрации сообщений сервера, включая stderr, csvlog и syslog. Задайте для этого параметра список желаемых пунктов назначения журнала, разделенных запятыми. По умолчанию вход только в stderr. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

  • Если csvlog включен в log_destination, записи журнала выводятся в формате "CSV"), что удобно для загрузки журналов в программы. См. раздел Использование вывода журнала в формате CSV для деталей. logging_collector должен быть включен для генерации вывода журнала в формате CSV.

  • Если включены либо stderr, либо csvlog, создается файл current_logfiles для записи местоположения файла (ов) журнала, который в данный момент используется сборщиком журналов, и связанного с ним места назначения журналирования. Это обеспечивает удобный способ поиска журналов, используемых в данный момент экземпляром. Вот пример содержимого этого файла:

stderr log/qhb.log
csvlog log/qhb.csv
  • current_logfiles воссоздается при создании нового файла журнала в результате поворота и при перезагрузке log_destination. Он удаляется, когда ни stderr, ни csvlog не включены в log_destination и когда сборщик журналов отключен.

Заметка
В большинстве систем Unix вам потребуется изменить конфигурацию демона системного журнала вашей системы, чтобы использовать параметр системного журнала для log_destination. QHB может регистрироваться в средствах системного журнала с LOCAL0 по LOCAL7 (см. Syslog_facility ), но конфигурация системного журнала по умолчанию на большинстве платформ отбрасывает все такие сообщения. Вам нужно будет добавить что-то вроде: local0. \* / var / log / qhb в файл конфигурации демона системного журнала, чтобы заставить его работать.

logging_collector (boolean)

  • Этот параметр включает сборщик журналов, который является фоновым процессом, который собирает сообщения журнала, отправленные в stderr, и перенаправляет их в файлы журнала. Этот подход часто более полезен, чем запись в системный журнал, поскольку некоторые типы сообщений могут не отображаться в выходных данных системного журнала. (Один из распространенных примеров - сообщения об ошибках динамического компоновщика; другой - сообщения об ошибках, создаваемые такими сценариями, как archive_command ). Этот параметр можно установить только при запуске сервера.

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

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

log_directory (string)

  • Когда logging_collector включен, этот параметр определяет каталог, в котором будут создаваться файлы журнала. Его можно указать как абсолютный путь или относительно каталога данных кластера. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. По умолчанию это log.

log_filename (string)

  • Когда logging_collector включен, этот параметр устанавливает имена созданных файлов журнала. Значение обрабатывается как шаблон strftime, поэтому % -escapes можно использовать для указания изменяющихся во времени имен файлов. (Обратите внимание, что при наличии % -escapes, зависящих от часового пояса, вычисления выполняются в зоне, указанной в log_timezone ). Поддерживаемые % -escapes аналогичны тем, которые перечислены в спецификации strftime Open Group. Обратите внимание, что системное время strftime не используется напрямую, поэтому специфичные для платформы (нестандартные) расширения не работают. По умолчанию используется qhb-%Y-%m-%d_%H%M%S.log.

  • Если вы указываете имя файла без экранирования, вы должны запланировать использование утилиты ротации журналов, чтобы в конечном итоге не заполнить весь диск. В выпусках до 8.4, если бы не было % escape, QHB добавлял бы эпоху времени создания нового файла журнала, но это больше не так.

  • Если вывод в формате ".csv" включен в log_destination, .csv будет добавлен к имени файла журнала с меткой времени, чтобы создать имя файла для вывода в формате CSV. (Если log_filename оканчивается на .log, вместо него заменяется суффикс).

  • Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

log_file_mode (integer)

  • В системах Unix этот параметр устанавливает разрешения для файлов журнала, когда включен logging_collector. (В Microsoft Windows этот параметр игнорируется). Ожидается, что значением параметра будет числовой режим, указанный в формате, принятом системными вызовами chmod и umask. (Для использования обычного восьмеричного формата число должно начинаться с 0 (ноль)).

  • Разрешения по умолчанию - 0600, что означает, что только владелец сервера может читать или записывать файлы журнала. Другой обычно полезный параметр - 0640, позволяющий членам группы владельца читать файлы. Однако обратите внимание, что для использования такой настройки вам нужно изменить log_directory, чтобы хранить файлы где-то за пределами каталога данных кластера. В любом случае неразумно делать файлы журналов доступными для чтения всем, поскольку они могут содержать конфиденциальные данные.

  • Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

log_rotation_age (integer)

  • Когда logging_collector включен, этот параметр определяет максимальное время использования отдельного файла журнала, после которого будет создан новый файл журнала. Если это значение указано без единиц измерения, оно принимается за минуты. По умолчанию это 24 часа. Установите в ноль, чтобы отключить создание новых файлов журнала на основе времени. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

log_rotation_size (integer)

  • Когда logging_collector включен, этот параметр определяет максимальный размер отдельного файла журнала. После того, как этот объем данных будет записан в файл журнала, будет создан новый файл журнала. Если это значение указано без единиц измерения, оно принимается за килобайты. По умолчанию 10 мегабайт. Установите в ноль, чтобы отключить создание новых файлов журнала на основе размера. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

log_truncate_on_rotation (boolean)

  • Когда logging_collector включен, этот параметр заставит QHB усекать (перезаписывать), а не добавлять к любому существующему файлу журнала с таким же именем. Однако усечение будет происходить только при открытии нового файла из-за ротации по времени, а не при запуске сервера или ротации по размеру. Если этот параметр отключен, во все случаи будут добавляться уже существующие файлы. Например, использование этого параметра в сочетании с qhb-%H.log например qhb-%H.log приведет к qhb-%H.log 24-часовых файлов журнала и их циклической перезаписи. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

  • Пример: чтобы хранить 7 дней журналов, один файл журнала в день с именем server_log.Mon, server_log.Tue и т. Д., И автоматически перезаписывать журнал прошлой недели с журналом этой недели, установите для log_filename значение server_log.%a log_truncate_on_rotation, log_truncate_on_rotation в on и log_rotation_age до 1440 .

  • Пример: чтобы хранить журналы в течение 24 часов, один файл журнала в час, но также вращаться раньше, если размер файла журнала превышает 1 ГБ, задайте для log_filename значение server_log.%H%M, log_truncate_on_rotation - on, log_rotation_age - 60 и log_rotation_size - 1000000. Включение %M в log_filename позволяет при любых вращениях на основе размера выбирать имя файла, отличное от начального имени файла часа.

syslog_facility (enum)

  • Когда вход в системный журнал включен, этот параметр определяет « средство » системного журнала, которое будет использоваться. Вы можете выбрать из LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7 ; по умолчанию это LOCAL0. Смотрите также документацию о системном демоне вашей системы. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

syslog_ident (string)

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

syslog_sequence_numbers (boolean)

  • При входе в системный журнал, который включен (по умолчанию), каждое сообщение будет иметь префикс возрастающего порядкового номера (например, [2]). Это позволяет обойти « --- последнее сообщение, повторенное N раз --- », которое многие реализации системного журнала выполняют по умолчанию. В более современных реализациях системного журнала можно настроить повторное подавление сообщений (например, $RepeatedMsgReduction RepeatedMsgReduction в rsyslog), поэтому это может быть необязательно. Кроме того, вы можете отключить это, если вы действительно хотите подавить повторяющиеся сообщения.

  • Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

syslog_split_messages (boolean)

  • Когда запись в системный журнал включена, этот параметр определяет способ доставки сообщений в системный журнал. При включении (по умолчанию) сообщения разделяются на строки, а длинные строки разделяются так, что они помещаются в 1024 байта, что является типичным пределом размера для традиционных реализаций системного журнала. Когда он выключен, сообщения журнала сервера QHB доставляются в службу системного журнала как есть, и служба системного журнала должна обрабатывать потенциально громоздкие сообщения.

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

  • Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

event_source (string)

  • Когда включена запись в журнал событий, этот параметр определяет имя программы, используемое для идентификации сообщений QHB в журнале. По умолчанию используется QHB. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

Когда писать в журнал

log_min_messages (enum)

  • Управляет тем, какие уровни сообщений записываются в журнал сервера. Допустимые значения: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL и PANIC. Каждый уровень включает в себя все уровни, которые следуют за ним. Чем позже уровень, тем меньше сообщений отправляется в журнал. По умолчанию установлено WARNING. Обратите внимание, что LOG имеет другой ранг, чем в client_min_messages. Только суперпользователи могут изменять эту настройку.

log_min_error_statement (enum)

  • Управляет тем, какие операторы SQL, вызывающие ошибку, записываются в журнал сервера. Текущий оператор SQL включается в запись журнала для любого сообщения указанной серьезности или выше. Допустимые значения: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL и PANIC. По умолчанию установлено значение ERROR, что означает, что в журнал будут записываться операторы, вызывающие ошибки, сообщения журнала, фатальные ошибки или паники. Чтобы эффективно отключить запись неудачных операторов, установите для этого параметра значение PANIC. Только суперпользователи могут изменять эту настройку.

log_min_duration_statement (integer)

  • Приводит к записи продолжительности каждого выполненного оператора, если оператор выполнялся как минимум указанное количество времени. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Установка этого значения в ноль печатает все длительности операторов. Минус один (по умолчанию) отключает продолжительность записи оператора. Например, если вы установите значение 250ms все операторы SQL, выполняющие 250 мс или более, будут записываться в журнал. Включение этого параметра может быть полезно для отслеживания неоптимизированных запросов в ваших приложениях. Только суперпользователи могут изменять эту настройку.

  • Для клиентов, использующих расширенный протокол запросов, длительности шагов Parse, Bind и Execute регистрируются независимо.

Заметка
При использовании этой опции вместе с log_statement текст операторов, которые регистрируются из-за log_statement, не будет повторяться в сообщении журнала продолжительности. Если вы не используете syslog, рекомендуется зарегистрировать PID или идентификатор сеанса с помощью log_line_prefix, чтобы можно было связать сообщение оператора с более поздним сообщением продолжительности, используя идентификатор процесса или идентификатор сеанса.

log_transaction_sample_rate (real)

  • Установите долю транзакций, чьи выписки все регистрируются, в дополнение к выпискам, зарегистрированным по другим причинам. Это применяется к каждой новой транзакции независимо от продолжительности ее заявлений. По умолчанию 0, что означает не регистрировать операторы от какой-либо дополнительной транзакции Установка этого значения в 1 регистрирует все операторы для всех транзакций. log_transaction_sample_rate полезен для отслеживания образца транзакции. Только суперпользователи могут изменять эту настройку.

Заметка
Как и все параметры ведения журнала выписок, эта опция может значительно увеличить накладные расходы.

Таблица 1 объясняет уровни серьезности сообщений, используемые QHB. Если выходные данные журнала отправляются в системный журнал или журнал событий Windows, уровни серьезности переводятся, как показано в таблице.

Таблица 1. Уровни серьезности сообщений

СтрогостьИспользованиеСистемный журналЖурнал событий
DEBUG1..DEBUG5Предоставляет последовательно-более подробную информацию для использования разработчиками.DEBUGINFORMATION
INFOПредоставляет информацию, неявно запрашиваемую пользователем, например, вывод из VACUUM VERBOSE.INFOINFORMATION
NOTICEПредоставляет информацию, которая может быть полезна пользователям, например, уведомление об усечении длинных идентификаторов.NOTICEINFORMATION
WARNINGПредоставляет предупреждения о возможных проблемах, например, COMMIT вне блока транзакции.NOTICEWARNING
ERRORСообщает об ошибке, которая привела к прерыванию текущей команды.WARNINGERROR
LOGСообщает информацию, представляющую интерес для администраторов, например, действия контрольных точек.INFOINFORMATION
FATALСообщает об ошибке, которая привела к прерыванию текущего сеанса.ERRERROR
PANICСообщает об ошибке, которая привела к прерыванию всех сеансов базы данных.CRITERROR

Что писать в журнал

application_name (string)

  • NAMEDATALEN может содержать любую строку длиной не более NAMEDATALEN символов (64 символа в стандартной сборке). Обычно он устанавливается приложением при подключении к серверу. Имя будет отображено в представлении pg_stat_activity и включено в записи журнала CSV. Она также может быть включен в регулярные записи в журнале через log_line_prefix параметра. В значении application_name могут использоваться только печатные символы ASCII. Другие символы будут заменены на вопросительные знаки (?).

    • debug_print_parse (boolean)

    • debug_print_rewritten (boolean)

    • debug_print_plan (boolean)

  • Эти параметры позволяют выводить различные выходные данные отладки. Когда установлено, они печатают результирующее дерево разбора, выходные данные программы переписывания запросов или план выполнения для каждого выполненного запроса. Эти сообщения отправляются на уровне сообщений LOG, поэтому по умолчанию они отображаются в журнале сервера, но не отправляются клиенту. Вы можете изменить это, настроив client_min_messages и / или log_min_messages. Эти параметры по умолчанию отключены.

debug_pretty_print (boolean)

  • Если установлено, debug_pretty_print от сообщений, созданных debug_print_parse, debug_print_rewritten или debug_print_plan. Это приводит к более удобочитаемому, но намного более длинному выводу, чем « компактный » формат, используемый, когда он выключен. Он включен по умолчанию.

log_checkpoints (boolean)

  • Заставляет контрольные точки и точки перезапуска регистрироваться в журнале сервера. Некоторая статистика включена в сообщения журнала, включая количество записанных буферов и время, потраченное на их запись. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. По умолчанию выключено.

log_connections (boolean)

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

Заметка
Некоторые клиентские программы, такие как psql, пытаются подключиться дважды, определяя, требуется ли пароль, поэтому повторяющиеся сообщения « соединение получено » не обязательно указывают на проблему.

log_disconnections (boolean)

  • Заставляет завершения сеанса регистрироваться. Вывод журнала предоставляет информацию, аналогичную log_connections, плюс продолжительность сеанса. Только суперпользователи могут изменять этот параметр при запуске сеанса, и его нельзя изменить вообще в течение сеанса. По умолчанию off .

log_duration (boolean)

  • Вызывает продолжительность каждого выполненного оператора для регистрации. По умолчанию off. Только суперпользователи могут изменять эту настройку.

  • Для клиентов, использующих расширенный протокол запросов, длительности шагов Parse, Bind и Execute регистрируются независимо.

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

log_error_verbosity (enum)

  • Управляет количеством сведений, записанных в журнале сервера для каждого зарегистрированного сообщения. Допустимые значения: TERSE, DEFAULT и VERBOSE, каждое из которых добавляет дополнительные поля к отображаемым сообщениям. TERSE исключает регистрацию информации об ошибках DETAIL, HINT, QUERY и CONTEXT. Вывод VERBOSE включает код ошибки SQLSTATE , а также имя файла исходного кода, имя функции и номер строки, которая вызвала ошибку. Только суперпользователи могут изменять эту настройку.

log_hostname (boolean)

  • По умолчанию в сообщениях журнала подключений отображается только IP-адрес подключающегося хоста. Включение этого параметра также приводит к регистрации имени хоста. Обратите внимание, что в зависимости от настройки разрешения имени вашего хоста это может привести к значительному снижению производительности. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

log_line_prefix (string)

  • Это строка в стиле printf которая выводится в начале каждой строки журнала. Символы % начинаются с « escape-последовательностей », которые заменяются информацией о состоянии, как показано ниже. Нераспознанные последовательности игнорируются. Другие символы копируются прямо в строку журнала. Некоторые экранирования распознаются только сессионными процессами и будут рассматриваться как пустые фоновыми процессами, такими как процесс основного сервера. Информация о состоянии может быть выровнена влево или вправо, указав числовой литерал после% и перед параметром. Отрицательное значение приведет к тому, что информация о состоянии будет дополнена справа пробелами для придания ей минимальной ширины, тогда как положительное значение будет дополнено слева. Заполнение может быть полезно для облегчения восприятия человеком файлов журнала. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера. По умолчанию используется значение ’%m [%p] ’ которое регистрирует отметку времени и идентификатор процесса.
ПоследовательностьЭффектТолько сессия
%aИмя приложенияда
%uИмя пользователяда
%dИмя базы данныхда
%rИмя удаленного хоста или IP-адрес, а также удаленный портда
%hИмя удаленного хоста или IP-адресда
%pИдентификатор процессанет
%tОтметка времени без миллисекунднет
%mОтметка времени с миллисекундаминет
%nОтметка времени с миллисекундами (как эпоха Unix)нет
%iТег команды: тип текущей команды сеансада
%eКод ошибки SQLSTATEнет
%cИдентификатор сеанса: см. Ниженет
%lНомер строки журнала для каждого сеанса или процесса, начиная с 1нет
%sОтметка времени начала процессанет
%vИдентификатор виртуальной транзакции (backendID / localXID)нет
%xID транзакции (0, если ни один не назначен)нет
%qНе выводит никаких данных, но указывает несессионным процессам остановиться в этой точке строки; игнорируется сессионными процессаминет
%%Буквальный %нет
  • %c escape печатает квазиуникальный идентификатор сеанса, состоящий из двух 4-байтовых шестнадцатеричных чисел (без начальных нулей), разделенных точкой. Числа - это время начала процесса и идентификатор процесса, поэтому %c также можно использовать как способ экономии места для печати этих элементов. Например, чтобы сгенерировать идентификатор сеанса из pg_stat_activity, используйте этот запрос:
SELECT to_hex(trunc(EXTRACT(EPOCH FROM backend_start))::integer) || '.' ||
     to_hex(pid)
FROM pg_stat_activity;

Заметка
Если вы устанавливаете непустое значение для log_line_prefix, вы обычно должны сделать его последний символ пробелом, чтобы обеспечить визуальное отделение от остальной части строки журнала. Также можно использовать знак пунктуации.

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

Заметка
Экранирование %q полезно при включении информации, доступной только в контексте сеанса (бэкенда), например имени пользователя или базы данных. Например: log_line_prefix = '%m [%p] %q%u@%d/%a '

log_lock_waits (boolean)

  • Управляет созданием сообщения журнала, когда сеанс ожидает дольше, чем deadlock_timeout, чтобы получить блокировку. Это полезно при определении того, вызывает ли ожидание блокировки низкую производительность. По умолчанию off. Только суперпользователи могут изменять эту настройку.

log_statement (enum)

  • Управляет тем, какие операторы SQL регистрируются. Допустимые значения: none (off), ddl, mod и all (все операторы). ddl регистрирует все операторы определения данных, такие как операторы CREATE, ALTER и DROP. mod регистрирует все операторы ddl, а также операторы изменения данных, такие как INSERT, UPDATE, DELETE, TRUNCATE и COPY FROM. PREPARE, EXECUTE и EXPLAIN ANALYZE также регистрируются, если содержащиеся в них команды имеют соответствующий тип. Для клиентов, использующих расширенный протокол запросов, ведение журнала происходит при получении сообщения Execute и включении значений параметров Bind (с удвоением всех встроенных одинарных кавычек).

  • По умолчанию none. Только суперпользователи могут изменять эту настройку.

Заметка
Операторы, которые содержат простые синтаксические ошибки, не регистрируются даже параметром log_statement = all, потому что сообщение журнала log_statement только после того, как был выполнен базовый анализ для определения типа оператора. В случае протокола расширенного запроса этот параметр также не регистрирует операторы, которые не выполняются до фазы выполнения (т. Е. Во время анализа анализа или планирования). Установите log_min_error_statement в ERROR (или ниже) для записи таких операторов.

log_replication_commands (boolean)

  • Заставляет каждую команду репликации регистрироваться в журнале сервера. Значение по умолчанию off. Только суперпользователи могут изменять эту настройку.

log_temp_files (integer)

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

log_timezone (string)

  • Устанавливает часовой пояс, используемый для отметок времени, записанных в журнале сервера. В отличие от TimeZone, это значение распространяется на весь кластер, поэтому все сеансы будут сообщать метки времени единообразно. Встроенное значение по умолчанию - GMT, но обычно оно переопределяется в qhb.conf; initdb установит там настройку, соответствующую системному окружению. См. раздел Часовые пояса для получения дополнительной информации. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

Использование вывода журнала в формате CSV

В том числе csvlog в log_destination списке обеспечивает удобный способ для импорта файлов журнала в таблицу базы данных. Эта опция генерирует строки журнала в формате значений, разделенных запятыми (CSV), со следующими столбцами: отметка времени с миллисекундами, имя пользователя, имя базы данных, идентификатор процесса, хост клиента: номер порта, идентификатор сеанса, номер строки для сеанса, команда тег, время начала сеанса, идентификатор виртуальной транзакции, идентификатор обычной транзакции, серьезность ошибки, код SQLSTATE, сообщение об ошибке, подробность сообщения об ошибке, подсказка, внутренний запрос, который привел к ошибке (если есть), количество символов в позиции ошибки, ошибка контекст, пользовательский запрос, который привел к ошибке (если таковой имеется и активирован log_min_error_statement), количество символов в позиции ошибки в нем, местоположение ошибки в исходном коде QHB (если для log_error_verbosity задано verbose ) и имя приложения. Вот пример определения таблицы для хранения вывода журнала в формате CSV:

CREATE TABLE postgres_log
(
  log_time timestamp(3) with time zone,
  user_name text,
  database_name text,
  process_id integer,
  connection_from text,
  session_id text,
  session_line_num bigint,
  command_tag text,
  session_start_time timestamp with time zone,
  virtual_transaction_id text,
  transaction_id bigint,
  error_severity text,
  sql_state_code text,
  message text,
  detail text,
  hint text,
  internal_query text,
  internal_query_pos integer,
  context text,
  query text,
  query_pos integer,
  location text,
  application_name text,
  PRIMARY KEY (session_id, session_line_num)
);

Чтобы импортировать файл журнала в эту таблицу, используйте команду COPY FROM :

COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;

Есть несколько вещей, которые необходимо сделать, чтобы упростить импорт файлов журнала CSV:

  1. Установите log_filename и log_rotation_age чтобы обеспечить согласованную, предсказуемую схему именования для ваших файлов журнала. Это позволяет вам предсказать, каким будет имя файла, и узнать, когда отдельный файл журнала будет завершен и, следовательно, готов к импорту.

  2. Установите для log_rotation_size значение 0, чтобы отключить ротацию журналов на основе размера, поскольку это затрудняет прогнозирование имени файла журнала.

  3. Установите для log_truncate_on_rotation значение on чтобы старые данные журнала не смешивались с новыми в том же файле.

  4. Приведенное выше определение таблицы содержит спецификацию первичного ключа. Это полезно для защиты от случайного импорта одной и той же информации дважды. Команда COPY фиксирует все импортируемые данные за один раз, поэтому любая ошибка приведет к сбою всего импорта. Если вы импортируете частичный файл журнала, а затем снова импортируете файл после его завершения, нарушение первичного ключа приведет к сбою импорта. Дождитесь завершения и закрытия журнала, прежде чем импортировать. Эта процедура также защитит от случайного импорта неполной строки, которая была написана не полностью, что также приведет к сбою COPY .

Название процесса

Эти параметры определяют, как изменяются заголовки процессов сервера. Названия процессов обычно просматриваются с помощью таких программ, как ps. Смотрите раздел Стандартные инструменты Unix для деталей.

cluster_name (string)

  • Устанавливает имя, которое идентифицирует этот кластер базы данных (экземпляр) для различных целей. Имя кластера появляется в заголовке процесса для всех процессов сервера в этом кластере. Кроме того, это имя приложения по умолчанию для резервного соединения (см. synchronous_standby_names ).

  • Имя может быть любой строкой длиной не более NAMEDATALEN символов (64 символа в стандартной сборке). В значении cluster_name можно использовать только печатные символы ASCII. Другие символы будут заменены на вопросительные знаки (?). Имя не отображается, если для этого параметра задана пустая строка ” (по умолчанию). Этот параметр можно установить только при запуске сервера.

update_process_title (boolean)

  • Позволяет обновлять заголовок процесса каждый раз, когда сервер получает новую команду SQL. Этот параметр по умолчанию включен на большинстве платформ, но по умолчанию он off в Windows из-за больших накладных расходов этой платформы при обновлении заголовка процесса. Только суперпользователи могут изменять эту настройку.

Статистика выполнения

Сборщик статистики запросов и индексов

Эти параметры управляют функциями сбора статистики на уровне сервера. Когда сбор статистики включен, к полученным данным можно получить доступ через семейство системных представлений pg_stat и pg_statio . Обратитесь к главе Мониторинг активности базы данных за дополнительной информацией.

track_activities (boolean)

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

track_activity_query_size (integer)

  • Определяет объем памяти, зарезервированный для хранения текста текущей выполняемой команды для каждого активного сеанса, для поля pg_stat_activity.query. Если это значение указано без единиц измерения, оно принимается как байты. Значение по умолчанию составляет 1024 байта. Этот параметр можно установить только при запуске сервера.

track_counts (boolean)

  • Включает сбор статистики о работе базы данных. Этот параметр включен по умолчанию, поскольку демону autovacuum требуется собранная информация. Только суперпользователи могут изменять эту настройку.

track_io_timing (boolean)

  • Включает синхронизацию вызовов ввода-вывода базы данных. По умолчанию этот параметр отключен, поскольку он будет периодически запрашивать у операционной системы текущее время, что может вызвать значительные издержки на некоторых платформах. Вы можете использовать инструмент pg_test_timing для измерения затрат времени в вашей системе. Информация о времени ввода / вывода отображается в pg_stat_database, в выходных данных EXPLAIN, когда используется опция BUFFERS, и в pg_stat_statements. Только суперпользователи могут изменять эту настройку.

track_functions (enum)

  • Позволяет отслеживать количество вызовов функций и использованное время. Укажите pl для отслеживания только функций процедурного языка, all также для отслеживания функций языка SQL и C/RUST. По умолчанию установлено значение none, что отключает отслеживание статистики функций. Только суперпользователи могут изменять эту настройку.

Заметка
Функции языка SQL, которые достаточно просты для « встраивания » в вызывающий запрос, отслеживаться не будут, независимо от этого параметра.

stats_temp_directory (string)

  • Устанавливает каталог для хранения временных данных статистики. Это может быть путь относительно каталога данных или абсолютный путь. По умолчанию используется pg_stat_tmp. Указание этого на файловую систему на основе ОЗУ снизит требования к физическому вводу-выводу и может привести к повышению производительности. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

Мониторинг статистики

log_statement_stats (boolean)

log_parser_stats (boolean)

log_planner_stats (boolean)

log_executor_stats (boolean)

Для каждого запроса выведите статистику производительности соответствующего модуля в журнал сервера. Это грубый инструмент профилирования, похожий на средство операционной системы Unix getrusage(). log_statement_stats сообщает общую статистику операторов, в то время как другие представляют статистику по модулям. log_statement_stats нельзя включить вместе с какими-либо опциями для каждого модуля. Все эти параметры по умолчанию отключены. Только суперпользователи могут изменять эти настройки.

Автоматический vacuum

Эти настройки управляют поведением функции автоочистки. Обратитесь к разделу [Процесс «Автовакуум»] за дополнительной информацией. Обратите внимание, что многие из этих настроек могут быть переопределены для каждой таблицы отдельно; см. Параметры хранения.

autovacuum (boolean)

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

log_autovacuum_min_duration (integer)

Заставляет регистрировать каждое действие, выполненное autovacuum, если оно выполнялось как минимум указанное количество времени. Установка этого в ноль регистрирует все действия автоочистки. -1 (по умолчанию) отключает запись действий автоочистки. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Например, если установить значение 250ms мс, будут регистрироваться все автоматические VACUUM и анализы, которые выполняются в течение 250 мс или более. Кроме того, если для этого параметра установлено любое значение, отличное от -1, сообщение будет записано в журнал, если действие автоочистки пропущено из-за конфликтующей блокировки или одновременного удаления отношения. Включение этого параметра может быть полезным для отслеживания активности автоочистки. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера; но параметр может быть переопределен для отдельных таблиц путем изменения параметров хранения таблиц.

autovacuum_max_workers (integer)

Задает максимальное количество процессов автоочистки (кроме запуска автоочистки), которые могут выполняться одновременно. По умолчанию три. Этот параметр можно установить только при запуске сервера.

autovacuum_naptime (integer)

Определяет минимальную задержку между запусками автоочистки в любой данной базе данных. В каждом раунде демон проверяет базу данных и при необходимости выдает команды VACUUM и ANALYZE для таблиц в этой базе данных. Если это значение указано без единиц измерения, оно принимается за секунды. По умолчанию используется одна минута (1min минута). Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

autovacuum_vacuum_threshold (integer)

Задает минимальное количество обновленных или удаленных кортежей, необходимое для запуска VACUUM в любой одной таблице. По умолчанию это 50 кортежей. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера; но параметр может быть переопределен для отдельных таблиц путем изменения параметров хранения таблиц.

autovacuum_analyze_threshold (integer)

Задает минимальное количество вставленных, обновленных или удаленных кортежей, необходимое для запуска ANALYZE в любой ANALYZE таблице. По умолчанию это 50 кортежей. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера; но параметр может быть переопределен для отдельных таблиц путем изменения параметров хранения таблиц.

autovacuum_vacuum_scale_factor (с floating point)

Определяет часть размера таблицы, добавляемую к autovacuum_vacuum_threshold при принятии решения о autovacuum_vacuum_threshold VACUUM. По умолчанию используется значение 0,2 (20% от размера таблицы). Этот параметр можно установить только в файле qhb.conf или в командной строке сервера; но параметр может быть переопределен для отдельных таблиц путем изменения параметров хранения таблиц.

autovacuum_analyze_scale_factor (с floating point)

Определяет часть размера таблицы, добавляемую к autovacuum_analyze_threshold при принятии решения о необходимости запуска ANALYZE. По умолчанию используется значение 0,1 (10% от размера таблицы). Этот параметр можно установить только в файле qhb.conf или в командной строке сервера; но параметр может быть переопределен для отдельных таблиц путем изменения параметров хранения таблиц.

autovacuum_freeze_max_age (integer)

Задает максимальный возраст (в транзакциях) для таблицы pg_class.relfrozenxid может быть relfrozenxid до того, как операция VACUUM будет вынуждена предотвратить relfrozenxid идентификатора транзакции в таблице. Обратите внимание, что система будет запускать процессы автоочистки, чтобы предотвратить циклическое изменение, даже если автовакуум отключен.

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

autovacuum_multixact_freeze_max_age (integer)

Задает максимальный возраст (в мультифакторах) таблицы pg_class.relminmxid может быть relminmxid до того, как операция VACUUM будет вынуждена предотвратить многофакторный перенос идентификатора в таблице. Обратите внимание, что система будет запускать процессы автоочистки, чтобы предотвратить циклическое изменение, даже если автовакуум отключен.

Вакуумирование мультифакторов также позволяет удалять старые файлы из pg_multixact/members и pg_multixact/offsets, поэтому по умолчанию это относительно небольшие 400 миллионов мультифакторов. Этот параметр можно установить только при запуске сервера, но его можно уменьшить для отдельных таблиц, изменив параметры хранения таблиц. Для получения дополнительной информации см. vacuumdb.

autovacuum_vacuum_cost_delay (с floating point)

Задает значение задержки стоимости, которое будет использоваться в автоматических операциях VACUUM. Если указано -1, будет использоваться обычное значение вакуума_коста. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Значение по умолчанию составляет 2 миллисекунды. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера; но параметр может быть переопределен для отдельных таблиц путем изменения параметров хранения таблиц.

autovacuum_vacuum_cost_limit (integer)

Указывает предельное значение стоимости, которое будет использоваться в автоматических операциях VACUUM. Если указано значение -1 (которое используется по умолчанию), будет использоваться обычное значениеuum_cost_limit. Обратите внимание, что это значение распределяется пропорционально между работающими потоками автоочистки, если их больше одного, так что сумма пределов для каждого потока не превышает значения этой переменной. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера; но параметр может быть переопределен для отдельных таблиц путем изменения параметров хранения таблиц.

Клиентское соединение по умолчанию

Поведение команд

client_min_messages (enum)

  • Управляет тем, какие уровни сообщений отправляются клиенту. Допустимые значения: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING и ERROR. Каждый уровень включает в себя все уровни, которые следуют за ним. Чем позже уровень, тем меньше сообщений отправляется. По умолчанию это NOTICE. Обратите внимание, что LOG имеет другой ранг, чем в log_min_messages .

  • Сообщения уровня INFO всегда отправляются клиенту.

search_path (string)

  • Эта переменная указывает порядок поиска схем, когда на объект (таблицу, тип данных, функцию и т. д). Ссылается простое имя без указания схемы. Когда в разных схемах есть объекты с одинаковыми именами, используется тот, который был найден первым в пути поиска. На объект, который не входит ни в одну из схем в пути поиска, можно ссылаться только путем указания его содержащей схемы с квалифицированным (пунктирным) именем.

  • Значение для search_path должно быть разделенным запятыми списком имен схем. Любое имя, которое не является существующей схемой или является схемой, для которой у пользователя нет разрешения USAGE, игнорируется.

  • Если одним из элементов списка является специальное имя $user, то схема с именем, возвращаемым CURRENT_USER, заменяется, если такая схема существует и у пользователя есть разрешение USAGE для нее. (Если нет, $user игнорируется).

  • Схема системного каталога, pg_catalog, всегда ищется, независимо от того, упоминается она в пути или нет. Если оно упомянуто в пути, то оно будет найдено в указанном порядке. Если pg_catalog не находится в пути, он будет pg_catalog перед поиском любого из элементов пути.

  • Аналогично, схема временной таблицы текущего сеанса, pg_temp_ nnn, всегда ищется, если она существует. Он может быть явно указан в пути с помощью псевдонима pg_temp, Если он не указан в пути, то он ищется первым (даже до pg_catalog). Однако во временной схеме ищутся только имена отношений (таблица, представление, последовательность и т.д). И имена типов данных. Никогда не ищется имя функции или оператора.

  • Когда объекты создаются без указания конкретной целевой схемы, они будут помещены в первую действительную схему с именем в search_path. Об ошибке сообщается, если путь поиска пуст.

  • Значением по умолчанию для этого параметра является "$user", public. Этот параметр поддерживает совместное использование базы данных (когда ни один пользователь не имеет частных схем, и все используют общее использование public ), частные схемы для каждого пользователя и их комбинации. Другие эффекты можно получить, изменив настройку пути поиска по умолчанию, глобально или для каждого пользователя.

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

  • Текущее эффективное значение пути поиска можно проверить с помощью функции SQL current_schemas (см. Раздел 9.25). Это не совсем то же самое, что изучение значения search_path, поскольку current_schemas показывает, как были разрешены элементы, появляющиеся в search_path .

row_security (boolean)

  • Эта переменная определяет, будет ли возникать ошибка вместо применения политики безопасности строк. Когда включено, политики применяются нормально. Если установлено значение off, запросы не выполняются, что в противном случае применило бы хотя бы одну политику. По умолчанию включено. off если ограниченная видимость строки может привести к неверным результатам; например, qhb_dump делает это изменение по умолчанию. Эта переменная не влияет на роли, которые обходят каждую политику безопасности строк, то есть на суперпользователей и роли с атрибутом BYPASSRLS .

  • Для получения дополнительной информации о политиках безопасности строк см. СОЗДАНИЕ ПОЛИТИКИ .

default_table_access_method (string)

  • Этот параметр указывает метод доступа к таблице по умолчанию, который используется при создании таблиц или материализованных представлений, если команда CREATE явно не указывает метод доступа или когда используется SELECT ... INTO, что не позволяет указать метод доступа к таблице. По умолчанию это heap .

default_tablespace (string)

  • Эта переменная задает табличное пространство по умолчанию, в котором создаются объекты (таблицы и индексы), когда команда CREATE явно не указывает табличное пространство. Он также определяет табличное пространство, в которое разделенное отношение будет направлять будущие разделы.

  • Значением является либо имя табличного пространства, либо пустая строка, указанная с использованием табличного пространства по умолчанию для текущей базы данных. Если значение не соответствует имени какого-либо существующего табличного пространства, QHB автоматически будет использовать табличное пространство по умолчанию для текущей базы данных. Если указано табличное пространство не по умолчанию, у пользователя должна быть привилегия CREATE, иначе попытки создания будут неудачными.

  • Эта переменная не используется для временных таблиц; для них вместо этого используется temp_tablespaces .

  • Эта переменная также не используется при создании баз данных. По умолчанию новая база данных наследует настройки табличного пространства из базы данных шаблонов, из которой она скопирована.

  • Для получения дополнительной информации о табличных пространствах см. раздел Табличные пространства.

temp_tablespaces (string)

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

  • Значение представляет собой список имен табличных пространств. Когда в списке более одного имени, QHB выбирает случайного члена списка каждый раз, когда создается временный объект; за исключением того, что внутри транзакции последовательно созданные временные объекты помещаются в последовательные табличные пространства из списка. Если выбранный элемент списка представляет собой пустую строку, QHB автоматически будет использовать табличное пространство по умолчанию для текущей базы данных.

  • Когда temp_tablespaces устанавливается интерактивно, указание несуществующего табличного пространства является ошибкой, как и указание табличного пространства, для которого у пользователя нет привилегии CREATE. Однако при использовании ранее установленного значения несуществующие табличные пространства игнорируются, как и табличные пространства, для которых у пользователя нет привилегии CREATE. В частности, это правило применяется при использовании значения, заданного в qhb.conf .

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

  • Смотрите также default_tablespace .

check_function_bodies (boolean)

  • Этот параметр обычно включен. Если установлено значение off, отключается проверка строки тела функции во время CREATE FUNCTION . Отключение проверки позволяет избежать побочных эффектов процесса проверки и избежать ложных срабатываний из-за проблем, таких как прямые ссылки. off этот параметр перед загрузкой функций от имени других пользователей; qhb_dump делает это автоматически.

default_transaction_isolation (enum)

  • Каждая транзакция SQL имеет уровень изоляции, который может быть « прочитано незафиксировано », « зафиксировано чтение », « повторяемое чтение » или « сериализуемо ». Этот параметр контролирует уровень изоляции по умолчанию для каждой новой транзакции. По умолчанию « передано на чтение » .

  • Обратитесь к главе Параллельный контроль и SET TRANSACTION для получения дополнительной информации.

default_transaction_read_only (boolean)

  • Доступная только для чтения транзакция SQL не может изменять временные таблицы. Этот параметр контролирует состояние по умолчанию только для чтения каждой новой транзакции. По умолчанию off (чтение / запись).

  • Обратитесь к SET TRANSACTION для получения дополнительной информации.

default_transaction_deferrable (boolean)

  • При выполнении на уровне serializable изоляции отложенная транзакция SQL только для чтения может быть отложена до того, как ей будет разрешено продолжить. Однако, как только он начинает выполняться, он не несет никаких накладных расходов, необходимых для обеспечения сериализуемости; поэтому у кода сериализации не будет причин принудительно прерывать его из-за одновременных обновлений, что делает эту опцию подходящей для длительных транзакций только для чтения.

  • Этот параметр управляет отложенным статусом по умолчанию для каждой новой транзакции. В настоящее время он не влияет на транзакции чтения-записи или те, которые работают на уровнях изоляции ниже, чем serializable. По умолчанию off .

  • Обратитесь к SET TRANSACTION для получения дополнительной информации.

session_replication_role (enum)

  • Управляет срабатыванием связанных с репликацией триггеров и правил для текущего сеанса. Установка этой переменной требует привилегий суперпользователя и приводит к отмене любых ранее кэшированных планов запросов. Возможные значения: origin (по умолчанию), replica и local .

  • Предполагаемое использование этого параметра заключается в том, что системы логической репликации устанавливают его для replica когда они применяют реплицированные изменения. В результате триггеры и правила (которые не были изменены из их конфигурации по умолчанию) не будут срабатывать на реплике. См. Разделы ALTER TABLE ENABLE TRIGGER и ENABLE RULE для получения дополнительной информации.

  • QHB обрабатывает исходные и local настройки одинаково. Сторонние системы репликации могут использовать эти два значения для своих внутренних целей, например, используя local для обозначения сеанса, изменения которого не должны реплицироваться.

  • Поскольку внешние ключи реализованы в виде триггеров, установка этого параметра на replica также отключает все проверки внешних ключей, которые могут привести к несогласованности данных в случае неправильного использования.

statement_timeout (integer)

  • Прервите любое утверждение, которое занимает больше указанного времени. Если для log_min_error_statement задано значение ERROR или ниже, тайм-аут оператора также будет записан в журнал. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Нулевое значение (по умолчанию) отключает тайм-аут.

  • Время ожидания измеряется с момента поступления команды на сервер до ее завершения сервером. В протоколе расширенных запросов тайм-аут начинает работать, когда поступает какое-либо связанное с запросом сообщение (Parse, Bind, Execute, Describe), и оно отменяется при завершении сообщения Execute или Sync.

  • Установка statement_timeout в qhb.conf не рекомендуется, потому что это повлияет на все сеансы.

lock_timeout (integer)

  • Прервите любой оператор, который ожидает дольше указанного времени, пытаясь получить блокировку таблицы, индекса, строки или другого объекта базы данных. Ограничение по времени применяется отдельно для каждой попытки получения блокировки. Ограничение применяется как к явным запросам блокировки (таким как LOCK TABLE или SELECT FOR UPDATE без NOWAIT ), так и к неявно полученным блокировкам. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Нулевое значение (по умолчанию) отключает тайм-аут.

  • В отличие от statement_timeout, этот тайм-аут может происходить только во время ожидания блокировок. Обратите внимание, что если lock_timeout отличен от нуля, бессмысленно устанавливать для lock_timeout то же самое или большее значение, поскольку время ожидания оператора всегда срабатывает первым. Если для log_min_error_statement задано значение ERROR или ниже, то выдержка времени будет записана в журнал.

  • Установка lock_timeout в qhb.conf не рекомендуется, потому что это повлияет на все сеансы.

idle_in_transaction_session_timeout (integer)

  • Завершите любой сеанс открытой транзакцией, которая простаивала дольше указанного времени. Это позволяет снять любые блокировки, удерживаемые этим сеансом, и повторно использовать слот подключения; это также позволяет вакуумировать кортежи, видимые только для этой транзакции. См. раздел Регулярный vacuum для более подробной информации об этом.

  • Если это значение указано без единиц измерения, оно принимается за миллисекунды. Нулевое значение (по умолчанию) отключает тайм-аут.

vacuum_freeze_table_age (integer)

  • VACUUM выполняет агрессивное сканирование, если таблица pg_class . relfrozenxid достигло возраста, указанного в этом параметре. Агрессивное сканирование отличается от обычного VACUUM тем, что оно посещает каждую страницу, которая может содержать незамерзающие XID или MXID, а не только те, которые могут содержать мертвые кортежи. По умолчанию 150 миллионов транзакций. Хотя пользователи могут установить это значение в диапазоне от нуля до двух миллиардов, VACUUM будет молча ограничивать эффективное значение до 95% autovacuum_freeze_max_age, чтобы периодическое руководство VACUUM могло запускаться до того, как для таблицы будет запущен автовакуум с обходом. Для получения дополнительной информации см. раздел Предотвращение ошибок обхода идентификатора транзакции.

vacuum_freeze_min_age (integer)

  • Определяет конечный возраст (в транзакциях), который VACUUM должен использовать, чтобы решить, следует ли заморозить версии строк при сканировании таблицы. По умолчанию 50 миллионов транзакций. Хотя пользователи могут установить это значение в диапазоне от нуля до одного миллиарда, VACUUM будет молча ограничивать эффективное значение до половины значения autovacuum_freeze_max_age, чтобы не было неоправданно короткого промежутка времени между принудительными автовакууумами. Для получения дополнительной информации см. раздел Предотвращение ошибок обхода идентификатора транзакции.

vacuum_multixact_freeze_table_age (integer)

  • VACUUM выполняет агрессивное сканирование, если таблица pg_class . relminmxid достигло возраста, указанного в этом параметре. Агрессивное сканирование отличается от обычного VACUUM тем, что оно посещает каждую страницу, которая может содержать незамерзающие XID или MXID, а не только те, которые могут содержать мертвые кортежи. По умолчанию установлено 150 миллионов мультифакторов. Хотя пользователи могут установить это значение в диапазоне от нуля до двух миллиардов, VACUUM будет молча ограничивать эффективное значение до 95% autovacuum_multixact_freeze_max_age, чтобы периодическое руководство VACUUM могло запускаться до того, как для таблицы будет запущен анти-циклический обход. Для получения дополнительной информации см. раздел [Мультифакторы и Wraparound].

vacuum_multixact_freeze_min_age (integer)

  • Определяет предельный возраст (в мультифакторах), который VACUUM должен использовать, чтобы решить, заменять ли многофакторные идентификаторы более новым идентификатором транзакции или многофакторным идентификатором при сканировании таблицы. По умолчанию используется 5 миллионов мультифакторов. Хотя пользователи могут установить это значение в диапазоне от нуля до одного миллиарда, VACUUM будет молча ограничивать эффективное значение половиной значения autovacuum_multixact_freeze_max_age, чтобы не было неоправданно короткого времени между принудительными автовакууумами. Для получения дополнительной информации см. раздел [Мультифакторы и Wraparound].

vacuum_cleanup_index_scale_factor (с floating point)

  • Указывает долю от общего числа кортежей кучи, подсчитанных в предыдущем сборе статистики, которые можно вставить без сканирования индекса на этапе очистки VACUUM. Этот параметр в настоящее время применяется только к B-деревьям.

  • Если из кучи не было удалено ни одного кортежа, B-деревья по-прежнему сканируются на этапе очистки VACUUM когда выполняется хотя бы одно из следующих условий: статистика индекса устарела или индекс содержит удаленные страницы, которые можно повторно использовать во время очистки, Статистика индекса считается устаревшей, если число вновь вставленных кортежей превышает долю в vacuum_cleanup_index_scale_factor от общего числа кортежей кучи, обнаруженных предыдущим сбором статистики. Общее количество кортежей кучи хранится на мета-странице индекса. Обратите внимание, что мета-страница не включает эти данные до тех пор, пока VACUUM не найдет мертвые кортежи, поэтому сканирование B-дерева на этапе очистки может быть пропущено, только если второй и последующие циклы VACUUM не обнаруживают мертвых кортежей.

  • Значение может варьироваться от 0 до 10000000000. Если в vacuum_cleanup_index_scale_factor установлено значение 0, сканирование индекса никогда не пропускается во время очистки VACUUM. Значение по умолчанию составляет 0.1 .

bytea_output (enum)

  • Устанавливает формат вывода для значений типа bytea. Допустимые значения: hex (по умолчанию) и escape (традиционный формат QHB). См. Раздел 8.4 для получения дополнительной информации. Тип bytea всегда принимает оба формата на входе, независимо от этого параметра.

xmlbinary (enum)

  • Устанавливает, как двоичные значения должны быть закодированы в XML. Это применимо, например, когда значения bytea конвертируются в XML с помощью функций xmlelement или xmlforest. Возможные значения: base64 и hex, которые определены в стандарте XML-схемы. По умолчанию используется base64. Для получения дополнительной информации о функциях, связанных с XML, см. Раздел 9.14 .

  • Фактический выбор здесь в основном зависит от вкуса, ограниченного только возможными ограничениями в клиентских приложениях. Оба метода поддерживают все возможные значения, хотя шестнадцатеричная кодировка будет несколько больше, чем кодировка base64.

xmloption (enum)

  • Устанавливает, является ли DOCUMENT или CONTENT неявным при преобразовании между значениями XML и символьных строк. См. раздел Тип XML для описания этого. Допустимые значения: DOCUMENT и CONTENT . По умолчанию используется CONTENT .

  • Согласно стандарту SQL, команда для установки этой опции

SET XML OPTION { DOCUMENT | CONTENT };

Этот синтаксис также доступен в QHB.

gin_pending_list_limit (integer)

  • Устанавливает максимальный размер списка ожидания индекса GIN, который используется при fastupdate. Если список становится больше этого максимального размера, он очищается путем массового перемещения записей в нем в основную структуру данных индекса GIN. Если это значение указано без единиц измерения, оно принимается за килобайты. По умолчанию используется четыре мегабайта (4MB). Этот параметр можно переопределить для отдельных индексов GIN, изменив параметры хранения индекса. См. раздел Быстрое обновление GIN и раздел GIN советы и хитрости для получения дополнительной информации.

Язык и форматирование

DateStyle (string)

  • Устанавливает формат отображения значений даты и времени, а также правила интерпретации неоднозначных значений ввода даты. По историческим причинам эта переменная содержит два независимых компонента: спецификацию выходного формата (ISO, Postgres, SQL или German) и спецификацию ввода / вывода для упорядочивания года / месяца / дня (DMY, MDY или YMD). Они могут быть установлены отдельно или вместе. Ключевые слова Euro и European являются синонимами для DMY; ключевые слова US, NonEuro и NonEuropean являются синонимами для MDY. См. раздел Типы даты / времени для получения дополнительной информации. По умолчанию встроенным является ISO, MDY, но initdb инициализирует файл конфигурации с настройкой, соответствующей поведению выбранного lc_time стандарта lc_time .

IntervalStyle (enum)

  • Устанавливает формат отображения для значений интервала. Значение sql_standard будет выдавать выходные данные, соответствующие литералам стандартного интервала SQL. Значение iso_8601 будет выдавать выходные данные, соответствующие временному интервалу «формат с указателями», определенному в разделе 4.4.3.2 ISO 8601.

  • Параметр IntervalStyle также влияет на интерпретацию ввода неоднозначных интервалов. См. раздел Формат ввода интервалов для получения дополнительной информации.

TimeZone (string)

  • Устанавливает часовой пояс для отображения и интерпретации меток времени. Встроенное значение по умолчанию - GMT, но обычно оно переопределяется в qhb.conf; initdb установит там настройку, соответствующую системному окружению. См. раздел Часовые пояса для получения дополнительной информации.

timezone_abbreviations (string)

  • Устанавливает коллекцию сокращений часовых поясов, которые будут приняты сервером для ввода даты и времени. По умолчанию используется значение ’Default’, которое является коллекцией, которая работает в большинстве стран мира; Есть также ’Australia’ и ’India’, и другие коллекции могут быть определены для конкретной установки. См. Раздел B.4 для получения дополнительной информации.

extra_float_digits (integer)

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

  • Если значение равно 1 (по умолчанию) или выше, значения с плавающей запятой выводятся в кратчайшем точном формате; см. раздел Типы с плавающей точкой. Фактическое количество генерируемых цифр зависит только от выводимого значения, а не от значения этого параметра. float8 значений float8 требуется не более 17 цифр, а для значений float4 9. Этот формат является быстрым и точным, сохраняя исходное двоичное значение с плавающей точкой точно при правильном чтении. Для исторической совместимости допустимы значения до 3.

  • Если значение равно нулю или отрицательно, то результат округляется до заданной десятичной точности. Используемая точность - это стандартное количество цифр для типа ( FLT_DIG или DBL_DIG в зависимости от ситуации), уменьшенное в соответствии со значением этого параметра. (Например, указание -1 приведет к float4 значения float4 будут округлены до 5 значащих цифр, а значения float8 округлены до 14 цифр). Этот формат медленнее и не сохраняет все биты двоичного значения с плавающей точкой, но может быть больше человек читаемый.

Заметка
см. раздел Типы с плавающей точкой для дальнейшего обсуждения.

client_encoding (string)

  • Устанавливает кодировку на стороне клиента (набор символов). По умолчанию используется кодировка базы данных. Наборы символов, поддерживаемые сервером QHB, описаны в разделе Поддерживаемые наборы символов.

lc_messages (string)

  • Устанавливает язык, на котором отображаются сообщения. Допустимые значения зависят от системы; см. раздел Поддержка локали для получения дополнительной информации. Если для этой переменной задана пустая строка (которая является значением по умолчанию), то значение наследуется от среды выполнения сервера системно-зависимым способом.

  • В некоторых системах эта категория локали не существует. Установка этой переменной все равно будет работать, но эффекта не будет. Кроме того, существует вероятность того, что переведенных сообщений на желаемом языке не существует. В этом случае вы будете продолжать видеть английские сообщения.

  • Только суперпользователи могут изменять этот параметр, поскольку он влияет на сообщения, отправляемые в журнал сервера, а также на клиент, и неправильное значение может затенить читаемость журналов сервера.

lc_monetary (string)

  • Устанавливает языковой стандарт для форматирования денежных сумм, например, с to_char семейства функций to_char. Допустимые значения зависят от системы; см. раздел Поддержка локали для получения дополнительной информации. Если для этой переменной задана пустая строка (которая является значением по умолчанию), то значение наследуется от среды выполнения сервера системно-зависимым способом.

lc_numeric (string)

  • Устанавливает языковой стандарт для форматирования чисел, например, с to_char семейства функций to_char. Допустимые значения зависят от системы; см. раздел Поддержка локали для получения дополнительной информации. Если для этой переменной задана пустая строка (которая является значением по умолчанию), то значение наследуется от среды выполнения сервера системно-зависимым способом.

lc_time (string)

  • Устанавливает языковой стандарт для форматирования даты и времени, например, с to_char семейства функций to_char. Допустимые значения зависят от системы; см. раздел Поддержка локали для получения дополнительной информации. Если для этой переменной задана пустая строка (которая является значением по умолчанию), то значение наследуется от среды выполнения сервера системно-зависимым способом.

default_text_search_config (string)

  • Выбирает конфигурацию текстового поиска, которая используется теми вариантами функций текстового поиска, у которых нет явного аргумента, определяющего конфигурацию. См. Главу 12 для получения дополнительной информации. Встроенное значение по умолчанию - pg_catalog.simple, но initdb инициализирует файл конфигурации с настройкой, соответствующей выбранной локали lc_ctype, если можно определить конфигурацию, соответствующую этой локали.

Предварительная загрузка общей библиотеки

Для предварительной загрузки общих библиотек на сервер доступно несколько параметров, чтобы загрузить дополнительные функции или повысить производительность. Например, установка ’$libdir/mylib’ приведет к mylib.so (или на некоторых платформах mylib.sl) из каталога стандартной библиотеки установки. Различия между настройками заключаются в том, когда они вступают в силу и какие привилегии требуются для их изменения.

Таким образом можно предварительно ’$libdir/plXXX’ библиотеки процедурного языка QHB, обычно используя синтаксис ’$libdir/plXXX’ где XXX - это pgsql, perl, tcl или python .

Только общие библиотеки, специально предназначенные для использования с QHB, могут быть загружены таким образом. Каждая библиотека, поддерживаемая QHB, имеет «магический блок», который проверяется на совместимость. По этой причине не-QHB библиотеки не могут быть загружены таким образом. Для этого вы можете использовать средства операционной системы, такие как LD_PRELOAD .

В общем, обратитесь к документации конкретного модуля за рекомендуемым способом загрузки этого модуля.

local_preload_libraries (string)

  • Эта переменная указывает одну или несколько общих библиотек, которые должны быть предварительно загружены при запуске подключения. Он содержит разделенный запятыми список имен библиотек, где каждое имя интерпретируется как для команды LOAD. Пробелы между записями игнорируются; окружите имя библиотеки двойными кавычками, если вам нужно включить пробел или запятые в имени. Значение параметра вступает в силу только в начале соединения. Последующие изменения не имеют никакого эффекта. Если указанная библиотека не найдена, попытка подключения завершится неудачно.

  • Эта опция может быть установлена любым пользователем. Из-за этого загружаемые библиотеки ограничены теми, которые появляются в подкаталоге plugins каталога стандартной библиотеки установки. (Администратор базы данных должен убедиться, что там установлены только « безопасные » библиотеки). Записи в local_preload_libraries могут явно указывать этот каталог, например, $libdir/plugins/mylib, или просто указывать имя библиотеки - mylib будет иметь то же самое эффект как $libdir/plugins/mylib .

  • Цель этой функции - позволить непривилегированным пользователям загружать библиотеки отладки или измерения производительности в конкретные сеансы, не требуя явной команды LOAD. Для этого было бы типично установить этот параметр с помощью переменной среды PGOPTIONS на клиенте или с помощью ALTER ROLE SET .

  • Однако, если модуль специально не предназначен для такого использования пользователями, не являющимися суперпользователями, обычно это неправильная настройка для использования. Вместо этого посмотрите на session_preload_libraries .

session_preload_libraries (string)

  • Эта переменная указывает одну или несколько общих библиотек, которые должны быть предварительно загружены при запуске подключения. Он содержит разделенный запятыми список имен библиотек, где каждое имя интерпретируется как для команды LOAD. Пробелы между записями игнорируются; окружите имя библиотеки двойными кавычками, если вам нужно включить пробел или запятые в имени. Значение параметра вступает в силу только в начале соединения. Последующие изменения не имеют никакого эффекта. Если указанная библиотека не найдена, попытка подключения завершится неудачно. Только суперпользователи могут изменять эту настройку.

  • Цель этой функции - позволить библиотекам отладки или измерения производительности загружаться в конкретные сеансы без явной команды LOAD. Например, auto_explain можно включить для всех сеансов с данным именем пользователя, установив этот параметр с помощью ALTER ROLE SET. Кроме того, этот параметр может быть изменен без перезапуска сервера (но изменения вступают в силу только при запуске нового сеанса), поэтому проще добавлять новые модули таким образом, даже если они должны применяться ко всем сеансам.

  • В отличие от shared_preload_libraries, нет большого преимущества в производительности при загрузке библиотеки при запуске сеанса, а не при его первом использовании. Однако при использовании пула соединений есть некоторое преимущество.

shared_preload_libraries (string)

  • Эта переменная указывает одну или несколько общих библиотек, которые должны быть предварительно загружены при запуске сервера. Он содержит разделенный запятыми список имен библиотек, где каждое имя интерпретируется как для команды LOAD. Пробелы между записями игнорируются; окружите имя библиотеки двойными кавычками, если вам нужно включить пробел или запятые в имени. Этот параметр можно установить только при запуске сервера. Если указанная библиотека не найдена, сервер не запустится.

  • Некоторые библиотеки должны выполнять определенные операции, которые могут выполняться только при запуске postmaster, такие как выделение общей памяти, резервирование легких блокировок или запуск фоновых рабочих. Эти библиотеки должны быть загружены при запуске сервера через этот параметр. Подробности смотрите в документации каждой библиотеки.

  • Другие библиотеки также могут быть предварительно загружены. За счет предварительной загрузки общей библиотеки время запуска библиотеки сокращается при первом использовании библиотеки. Однако время запуска каждого нового серверного процесса может немного увеличиться, даже если этот процесс никогда не использует библиотеку. Поэтому этот параметр рекомендуется только для библиотек, которые будут использоваться в большинстве сеансов. Кроме того, изменение этого параметра требует перезапуска сервера, так что, скажем, это неправильная настройка для краткосрочных задач отладки. Вместо этого используйте для этого session_preload_libraries .

Заметка
На хостах Windows предварительная загрузка библиотеки при запуске сервера не сократит время, необходимое для запуска каждого нового процесса сервера; каждый процесс сервера перезагрузит все библиотеки предварительной загрузки. Тем не менее, shared_preload_libraries все еще полезен на хостах Windows для библиотек, которые должны выполнять операции во время запуска postmaster.

jit_provider (string)

  • Эта переменная является именем используемой библиотеки провайдера JIT . По умолчанию используется llvmjit. Этот параметр можно установить только при запуске сервера.

  • Если задана несуществующая библиотека, JIT будет недоступен, но ошибки не возникнет. Это позволяет устанавливать поддержку JIT отдельно от основного пакета QHB .

Другие значения по умолчанию

dynamic_library_path (string)

  • Если необходимо открыть динамически загружаемый модуль и имя файла, указанное в команде CREATE FUNCTION или LOAD, не имеет компонента каталога (т. Е. Имя не содержит косую черту), система будет искать этот путь для поиска требуемого файла.

  • Значение для dynamic_library_path должно быть списком абсолютных путей к каталогам, разделенных двоеточиями (или точками с запятой в Windows). Если элемент списка начинается со специальной строки $libdir, $libdir скомпилированной библиотеки пакетов QHB заменяется на $libdir; Здесь устанавливаются модули, предоставляемые стандартным дистрибутивом QHB. (Используйте pg_config --pkglibdir чтобы узнать имя этого каталога). Например:

dynamic_library_path = '/usr/local/qhb/lib:/home/my_project/lib:$libdir'
  • Значением по умолчанию для этого параметра является ’$libdir’. Если в качестве значения задана пустая строка, автоматический поиск пути отключается.

  • Этот параметр может быть изменен суперпользователями во время выполнения, но настройка, выполненная таким образом, будет сохраняться только до конца клиентского соединения, поэтому этот метод должен быть зарезервирован для целей разработки. Рекомендуемый способ установить этот параметр - в файле конфигурации qhb.conf .

gin_fuzzy_search_limit (integer)

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

Управление блокировками

deadlock_timeout (integer)

  • Это время ожидания блокировки перед проверкой наличия тупиковой ситуации. Проверка на взаимоблокировку является относительно дорогой, поэтому сервер не запускает ее каждый раз, когда ожидает блокировки. Мы с оптимизмом предполагаем, что взаимные блокировки не распространены в рабочих приложениях, и просто подождем некоторое время, прежде чем проверять наличие взаимоблокировок. Увеличение этого значения уменьшает количество времени, затрачиваемого на ненужные проверки взаимоблокировок, но замедляет сообщение о реальных ошибках взаимоблокировок. Если это значение указано без единиц измерения, оно принимается за миллисекунды. Значение по умолчанию составляет одну секунду (1s), что, вероятно, соответствует наименьшему значению, которое вы хотели бы получить на практике. На сильно загруженном сервере вы можете поднять его. В идеале настройка должна превышать ваше типичное время транзакции, чтобы повысить вероятность того, что блокировка будет снята до того, как официант решит проверить тупик. Только суперпользователи могут изменять эту настройку.

  • Когда установлен параметр log_lock_waits, этот параметр также определяет время ожидания, прежде чем будет выдано сообщение журнала об ожидании блокировки. Если вы пытаетесь исследовать задержки блокировки, вы можете установить короче обычного deadlock_timeout .

max_locks_per_transaction (integer)

  • Таблица общих блокировок отслеживает блокировки max_locks_per_transaction * ( max_connections + max_prepared_transactions ) (например, таблиц); следовательно, не больше, чем это множество различных объектов могут быть заблокированы одновременно. Этот параметр контролирует среднее количество блокировок объектов, выделенных для каждой транзакции; отдельные транзакции могут блокировать больше объектов, если блокировки всех транзакций помещаются в таблицу блокировок. Это не количество строк, которые могут быть заблокированы; эта ценность не ограничена. Значение по умолчанию, 64, исторически доказано достаточным, но вам может потребоваться повысить это значение, если у вас есть запросы, которые касаются множества разных таблиц в одной транзакции, например, запрос родительской таблицы с множеством дочерних элементов. Этот параметр можно установить только при запуске сервера.

  • При запуске резервного сервера вы должны установить для этого параметра то же или более высокое значение, чем на главном сервере. В противном случае запросы не будут разрешены на резервном сервере.

max_pred_locks_per_transaction (integer)

  • Общая таблица блокировки предикатов отслеживает блокировки max_pred_locks_per_transaction * ( max_connections + max_prepared_transactions ) (например, таблиц); следовательно, не больше, чем это множество различных объектов могут быть заблокированы одновременно. Этот параметр контролирует среднее количество блокировок объектов, выделенных для каждой транзакции; отдельные транзакции могут блокировать больше объектов, если блокировки всех транзакций помещаются в таблицу блокировок. Это не количество строк, которые могут быть заблокированы; эта ценность не ограничена. Стандартное значение 64 обычно достаточно для тестирования, но вам может потребоваться увеличить это значение, если у вас есть клиенты, которые касаются множества разных таблиц в одной сериализуемой транзакции. Этот параметр можно установить только при запуске сервера.

max_pred_locks_per_relation (integer)

  • Это контролирует, сколько страниц или кортежей одного отношения может быть заблокировано предикатом, прежде чем блокировка будет повышена до полного отношения. Значения, большие или равные нулю, означают абсолютный предел, а отрицательные значения означают max_pred_locks_per_transaction, деленное на абсолютное значение этого параметра. По умолчанию используется значение -2, которое сохраняет поведение предыдущих версий QHB. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

max_pred_locks_per_page (integer)

  • Это контролирует, сколько строк на одной странице может быть заблокировано предикатом, прежде чем блокировка будет повышена до всей страницы. Значение по умолчанию - 2. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

Совместимость версий и платформ

Предыдущие версии QHB

array_nulls (boolean)

  • Определяет, распознает ли входной синтаксический анализатор массива NULL кавычек как указание элемента массива null. По умолчанию это включено, что позволяет вводить значения массива, содержащие нулевые значения.

  • Обратите внимание, что можно создавать значения массива, содержащие нулевые значения, даже если эта переменная off.

backslash_quote (enum)

  • Это определяет, может ли знак кавычки быть представлен \’ в строковом литерале. Предпочтительный стандартный способ представления знака кавычки в SQL - это удвоение его (”), но QHB также принимает \’. Однако использование \’ создает риски безопасности, потому что в некоторых кодировках клиентского набора символов существуют многобайтовые символы, в которых последний байт численно эквивалентен ASCII \. Если код на стороне клиента экранирует некорректно, то возможна атака SQL-инъекцией. Этот риск можно предотвратить, заставив сервер отклонять запросы, в которых знак кавычки, по-видимому, экранирован обратной косой чертой. Допустимые значения backslash_quote : safe_encoding (всегда разрешено), off (всегда отклонено) и безопасное safe_encoding (разрешено только в том случае, если клиентское кодирование не позволяет ASCII \ в многобайтовом символе). safe_encoding является настройкой по умолчанию.

  • Обратите внимание, что в строковом литерале, соответствующем стандарту, в любом случае \ just означает \. Этот параметр влияет только на обработку нестандартных литералов, включая синтаксис escape-строки (E’...’).

escape_string_warning (boolean)

  • Когда включено, выдается предупреждение, если в обычном строковом литерале (’...’ синтаксис) появляется обратная косая черта (\), а standard_conforming_strings выключено. По умолчанию включено.

  • Приложения, которые хотят использовать обратную косую черту в качестве escape, должны быть модифицированы для использования синтаксиса escape-строки (E’...’), потому что поведение обычных строк по умолчанию теперь обрабатывает обратную косую черту как обычный символ в соответствии со стандартом SQL. Эта переменная может быть включена, чтобы помочь найти код, который необходимо изменить.

lo_compat_privileges (boolean)

  • Установка этой переменной в положение on отключает новые проверки привилегий для совместимости с предыдущими выпусками. По умолчанию off. Только суперпользователи могут изменять эту настройку.

  • Установка этой переменной отключает не все проверки безопасности, связанные с большими объектами.

operator_precedence_warning (boolean)

  • Когда он включен, синтаксический анализатор будет выдавать предупреждение для любой конструкции, которая могла бы изменить значения, в результате изменений в приоритетах операторов. Это полезно для аудита приложений, чтобы увидеть, не изменились ли изменения приоритета; но он не предназначен для того, чтобы его оставляли включенным в работе, поскольку он будет предупреждать о каком-то совершенно корректном, стандартно совместимом коде SQL. По умолчанию off .

  • См. раздел Приоритет оператора для получения дополнительной информации.

quote_all_identifiers (boolean)

  • Когда база данных генерирует SQL, принудительно заключите в кавычки все идентификаторы, даже если они не являются (в настоящее время) ключевыми словами. Это повлияет на вывод EXPLAIN а также на результаты функций, таких как pg_get_viewdef. Смотрите также параметр --quote-all-identifiers в qhb_dump и qhb_dumpall.

standard_conforming_strings (boolean)

  • Контролирует, будут ли обычные строковые литералы (’...’) обрабатывать обратную косую черту буквально, как указано в стандарте SQL. По умолчанию включено. Приложения могут проверить этот параметр, чтобы определить, как будут обрабатываться строковые литералы. Наличие этого параметра также может рассматриваться как указание на то, что синтаксис escape-строки (E’...’) поддерживается. Синтаксис Escape-строки (раздел Строковые константы с экранированием в стиле C) следует использовать, если приложение хочет, чтобы обратные слэши обрабатывались как escape-символы.

synchronize_seqscans (boolean)

Это позволяет синхронизировать друг с другом последовательное сканирование больших таблиц, так что одновременное сканирование считывает один и тот же блок примерно в одно и то же время и, следовательно, разделяет рабочую нагрузку ввода-вывода. Когда это включено, сканирование может начаться в середине таблицы, а затем « обернуться» вокруг конца, чтобы покрыть все строки, чтобы синхронизироваться с активностью сканирований, которые уже выполняются. Это может привести к непредсказуемым изменениям порядка строк, возвращаемых запросами, в которых нет предложения ORDER BY. Отключение этого параметра обеспечивает поведение до 8.3, при котором последовательное сканирование всегда начинается с начала таблицы. По умолчанию включено.

Совместимость платформы и клиента

transform_null_equals (boolean)

  • Когда включено, выражения вида expr = NULL (или NULL = expr) обрабатываются как expr IS NULL, то есть они возвращают true, если expr оценивается как нулевое значение, и false в противном случае. Правильное SQL-совместимое поведение expr = NULL - всегда возвращать ноль (неизвестно). Поэтому этот параметр по умолчанию off .

  • Однако отфильтрованные формы в Microsoft Access генерируют запросы, которые, по-видимому, используют expr = NULL для проверки на нулевые значения, поэтому, если вы используете этот интерфейс для доступа к базе данных, вы можете включить эту опцию. Поскольку выражения вида expr = NULL всегда возвращают нулевое значение (используя стандартную интерпретацию SQL), они не очень полезны и не часто появляются в обычных приложениях, поэтому этот параметр на практике приносит мало вреда. Но новых пользователей часто смущает семантика выражений, содержащих нулевые значения, поэтому по умолчанию эта опция отключена.

  • Обратите внимание, что этот параметр влияет только на точную форму = NULL, но не на другие операторы сравнения или другие выражения, которые в вычислительном отношении эквивалентны некоторому выражению, включающему оператор равенства (например, IN). Таким образом, эта опция не является общим исправлением для плохого программирования.

  • Обратитесь к разделу Функции сравнения и операторы за соответствующей информацией.

Обработка ошибок

exit_on_error (boolean)

  • Если включено, любая ошибка прервет текущий сеанс. По умолчанию это отключено, так что только ФАТАЛЬНЫЕ ошибки прервут сеанс.

restart_after_crash (boolean)

  • Если установлено значение on, которое используется по умолчанию, QHB автоматически переинициализируется после сбоя бэкэнда. Если оставить это значение включенным, обычно это лучший способ максимизировать доступность базы данных. Однако в некоторых обстоятельствах, например, когда QHB вызывается кластерным программным обеспечением, может быть полезно отключить перезапуск, чтобы кластерное программное обеспечение могло получить контроль и предпринимать любые действия, которые оно сочтет целесообразными.

data_sync_retry (boolean)

  • Если установлено значение off, которое используется по умолчанию, QHB выдаст ошибку уровня PANIC при невозможности сброса измененных файлов данных в файловую систему. Это приводит к сбою сервера базы данных. Этот параметр можно установить только при запуске сервера.

  • В некоторых операционных системах состояние данных в кеше страниц ядра после сбоя обратной записи неизвестно. В некоторых случаях это могло быть полностью забыто, что делает небезопасным повторение; вторая попытка может быть объявлена успешной, когда фактически данные были потеряны. В этих обстоятельствах единственный способ избежать потери данных - это восстановление из WAL после того, как сообщается о любом сбое, предпочтительно после расследования основной причины сбоя и замены любого неисправного оборудования.

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

Предустановленные параметры

Следующие « параметры » доступны только для чтения и определяются при компиляции QHB или при его установке. Как таковые, они были исключены из примера файла qhb.conf. Эти опции сообщают о различных аспектах поведения QHB, которые могут представлять интерес для определенных приложений, в частности, административных интерфейсов.

block_size (integer)

  • Сообщает размер блока диска. Это определяется значением BLCKSZ при сборке сервера. Значение по умолчанию составляет 8192 байта. Значение некоторых переменных конфигурации (например, shared_buffers ) зависит от block_size. См. раздел Потребление ресурсов для информации.

data_checksums (boolean)

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

data_directory_mode (integer)

  • В системах Unix этот параметр сообщает о разрешениях каталога данных, определенных (data_directory) при запуске. (В Microsoft Windows этот параметр всегда будет отображать 0700 ). Смотрите групповой доступ для получения дополнительной информации.

debug_assertions (boolean)

  • Сообщает, был ли QHB собран с включенными утверждениями. Это тот случай, если макрос USE_ASSERT_CHECKING определен при USE_ASSERT_CHECKING QHB (выполняется, например, с configure параметра configure --enable-cassert ). По умолчанию QHB собран без утверждений.

integer_datetimes (boolean)

  • Сообщает, был ли построен QHB с поддержкой 64-битных целых дат и времени. По умолчанию - on.

lc_collate (string)

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

lc_ctype (string)

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

max_function_args (integer)

  • Сообщает максимальное количество аргументов функции. Это определяется значением FUNC_MAX_ARGS при сборке сервера. Значение по умолчанию составляет 100 аргументов.

max_identifier_length (integer)

  • Сообщает максимальную длину идентификатора. Он определяется на единицу меньше значения NAMEDATALEN при сборке сервера. Значение по умолчанию NAMEDATALEN - 64; поэтому значение по умолчанию max_identifier_length составляет 63 байта, что может быть меньше 63 символов при использовании многобайтовых кодировок.

max_index_keys (integer)

  • Сообщает максимальное количество индексных ключей. Это определяется значением INDEX_MAX_KEYS при сборке сервера. Значение по умолчанию составляет 32 ключа.

segment_size (integer)

  • Сообщает о количестве блоков (страниц), которые могут быть сохранены в сегменте файла. Это определяется значением RELSEG_SIZE при сборке сервера. Максимальный размер файла сегмента в байтах равен block_size умноженному на block_size; по умолчанию это 1 ГБ.

server_encoding (string)

  • Сообщает кодировку базы данных (набор символов). Определяется при создании базы данных. Обычно клиенты должны иметь дело только со значением client_encoding .

server_version (string)

  • Сообщает номер версии сервера. Это определяется значением PG_VERSION при сборке сервера.

server_version_num (integer)

  • Сообщает номер версии сервера как целое число. Это определяется значением PG_VERSION_NUM при сборке сервера.

ssl_library (string)

  • Сообщает имя библиотеки SSL, с которой был построен этот сервер QHB (даже если SSL в настоящее время не настроен или не используется в этом экземпляре), например OpenSSL, или пустая строка, если ее нет.

wal_block_size (integer)

  • Сообщает размер блока диска WAL. Это определяется значением XLOG_BLCKSZ при сборке сервера. Значение по умолчанию составляет 8192 байта.

wal_segment_size (integer)

  • Сообщает размер сегментов журнала записи вперед. Значение по умолчанию составляет 16 МБ. См. Раздел 29.4 для получения дополнительной информации.

Индивидуальные параметры

Эта функция была разработана для того, чтобы позволить параметрам, обычно не известным QHB, добавляться дополнительными модулями (такими как процедурные языки). Это позволяет настраивать модули расширения стандартными способами.

У пользовательских параметров есть имена из двух частей: имя расширения, затем точка, затем собственно имя параметра, очень похожее на квалифицированные имена в SQL. Примером является plpgsql.variable_conflict .

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

Параметры разработчика

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

allow_system_table_mods (boolean)

  • Позволяет изменять структуру системных таблиц. Это используется initdb. Этот параметр можно установить только при запуске сервера.

ignore_system_indexes (boolean)

  • Игнорировать системные индексы при чтении системных таблиц (но все же обновлять индексы при изменении таблиц). Это полезно при восстановлении с поврежденных системных индексов. Этот параметр нельзя изменить после начала сеанса.

post_auth_delay (integer)

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

pre_auth_delay (integer)

  • Время задержки сразу после того, как новый процесс сервера разветвлен, прежде чем он выполнит процедуру аутентификации. Это предназначено для того, чтобы дать разработчикам возможность подключиться к процессу сервера с помощью отладчика для отслеживания неправильного поведения при аутентификации. Если это значение указано без единиц измерения, оно принимается за секунды. Нулевое значение (по умолчанию) отключает задержку. Этот параметр можно установить только в файле qhb.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 это приводит к безоговорочной отправке их в журнал сервера. Этот параметр можно установить только в файле qhb.conf или в командной строке сервера.

trace_sort (boolean)

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

trace_lwlocks (boolean)

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

  • Этот параметр доступен только в том случае, если макрос LOCK_DEBUG был определен при компиляции QHB .

trace_userlocks (boolean)

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

  • Этот параметр доступен только в том случае, если макрос LOCK_DEBUG был определен при компиляции QHB .

trace_lock_oidmin (integer)

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

  • Этот параметр доступен только в том случае, если макрос LOCK_DEBUG был определен при компиляции QHB .

trace_lock_table (integer)

  • Безоговорочно проследите блокировки на этой таблице (OID).

  • Этот параметр доступен только в том случае, если макрос LOCK_DEBUG был определен при компиляции QHB .

debug_deadlocks (boolean)

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

  • Этот параметр доступен только в том случае, если макрос LOCK_DEBUG был определен при компиляции QHB .

log_btree_build_stats (boolean)

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

  • Этот параметр доступен только в том случае, если макрос BTREE_BUILD_STATS был определен при компиляции QHB .

wal_consistency_checking (string)

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

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

wal_debug (boolean)

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

ignore_checksum_failure (boolean)

  • Имеет эффект только если контрольные суммы данных включены.

  • Обнаружение ошибки контрольной суммы во время чтения обычно заставляет QHB сообщать об ошибке, прерывая текущую транзакцию. Если для параметра ignore_checksum_failure установлено ignore_checksum_failure on, система игнорирует ошибку (но все равно ignore_checksum_failure предупреждение) и продолжает обработку. Такое поведение может вызвать сбои, распространение или скрытие коррупции или других серьезных проблем. Тем не менее, это может позволить вам обойти ошибку и извлечь неповрежденные кортежи, которые все еще могут присутствовать в таблице, если заголовок блока все еще в здравом уме. Если заголовок поврежден, будет сообщено об ошибке, даже если эта опция включена. Настройка по умолчанию off, и она может быть изменена только суперпользователем.

zero_damaged_pages (boolean)

  • Обнаружение поврежденного заголовка страницы обычно заставляет QHB сообщать об ошибке, прерывая текущую транзакцию. Если для параметра zero_damaged_pages установлено zero_damaged_pages on, система вместо этого отправит предупреждение, zero_damaged_pages поврежденную страницу в памяти и продолжит обработку. Такое поведение уничтожит данные, а именно все строки на поврежденной странице. Однако он позволяет обойти ошибку и извлечь строки из любых неповрежденных страниц, которые могут присутствовать в таблице. Это полезно для восстановления данных, если произошло повреждение из-за аппаратной или программной ошибки. Обычно вы не должны устанавливать это, пока не оставите надежду восстановить данные с поврежденных страниц таблицы. Страницы с нулевым удалением не записываются на диск, поэтому рекомендуется заново создать таблицу или индекс, прежде чем снова отключить этот параметр. Настройка по умолчанию off, и она может быть изменена только суперпользователем.

jit_debugging_support (boolean)

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

jit_dump_bitcode (boolean)

  • Записывает сгенерированный IR LLVM в файловую систему внутри data_directory. Это полезно только для работы над внутренними компонентами реализации JIT. Настройка по умолчанию off. Этот параметр может быть изменен только суперпользователем.

jit_expressions (boolean)

  • Определяет, скомпилированы ли выражения JIT, когда JIT-компиляция активирована . По умолчанию включено.

jit_profiling_support (boolean)

  • Если LLVM обладает необходимой функциональностью, отправьте данные, необходимые для разрешения функции профилирования, сгенерированной JIT. Это записывает файлы в $HOME/.debug/jit/; пользователь несет ответственность за выполнение очистки при желании. Настройка по умолчанию off. Этот параметр можно установить только при запуске сервера.

jit_tuple_deforming (boolean)

  • Определяет, деформируется ли кортеж JIT, когда JIT-компиляция активирована . По умолчанию включено.

Сокращения командной строки

Для удобства имеются также однобуквенные параметры командной строки, доступные для некоторых параметров. Они описаны в таблице 4.2 . Некоторые из этих опций существуют по историческим причинам, и их наличие в виде однобуквенной опции не обязательно означает одобрение использования этой опции.

Таблица 2. Короткий ключ

Короткий вариантЭквивалент
-B xshared_buffers = x
-d xlog_min_messages = DEBUG x
-edatestyle = euro
-fb, -fb, -fh, -fm, -fn, -fo, -fs, -ftenable_bitmapscan = off, enable_hashjoin = off, enable_indexscan = off, enable_mergejoin = off, enable_nestloop = off, enable_indexonlyscan = off, enable_seqscan = off, enable_tidscan = off
-Ffsync = off
-h xlisten_addresses = x
-ilisten_addresses = ’*’
-k xunix_socket_directories = x
-lssl = on
-N xmax_connections = x
-Oallow_system_table_mods = on
-p xport = x
-Pignore_system_indexes = on
-slog_statement_stats = on
-S xwork_mem = x
-tpa, -tpl, -telog_parser_stats = on log_planner_stats = on, log_executor_stats = on, log_executor_stats = on
-W xpost_auth_delay = x

Предотвращение ошибок обхода идентификатора транзакции: qhb_maintenance.md#Предотвращение-ошибок-закольцовывания- идентификатора-транзакции [Мультифакторы и Wraparound]: qhb_maintenance.md#Мультифакторы-и-wraparound [Процесс «Автовакуум»]: qhb_maintenance.md#Процесс-Автовакуум