Все имена параметров нечувствительны к регистру. Каждый параметр принимает значение одного из пяти типов: boolean, string, integer, floating point или enumerated (enum). Тип определяет синтаксис для установки параметра:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

include 'filename'

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

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

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

include_dir 'directory'

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

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

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

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

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

include_dir 'conf.d'

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

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

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

Вы можете вместо этого использовать следующий подход к именованию файлов описательно:

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

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