Почему PostgreSQL игнорирует мои настройки?
Время от времени сталкиваемся с таким вопросом от читателей и коллег. Обычно он возникает после того, как были изменены настройки в конфигурационном файле, но почему-то не применились.
На самом деле все просто, для конфигурационных файлов PostgreSQL действует правило – если настройка перечислена файле несколько раз, то применятся та из них, которая была прочитана последней.
Как и многие другие Linux-приложения PostgreSQL поддерживает технологию включения (include), т.е. мы может вынести настройки в отдельные конфигурационные файлы, указать к ним путь в настройках приложения, и они будут применены в том месте конфигурации, где подключаются директивой include.
В конфигурационном файле PostgreSQL она располагается в самом конце и применяется последней, что гарантирует перекрытие всех ранее указанных настроек. Сама директория с файлами include (обычно conf.d) может содержать несколько конфигурационных файлов, которые читаются в алфавитном порядке.
Но и это еще не все, многие администраторы и даже разработчики (например, PostgresPRO) практикуют выносит изменения в самый конец конфигурационного файла и на первом скриншоте как раз видна такая секция, сделанная при автоматической оптимизации версии сервера СУБД от PostgresPRO.
Такой подход имеет неоспоримые плюсы. Во-первых, ваши настройки гарантированно применятся и будут иметь приоритет над остальными. Во-вторых, все они в одном месте и вам не надо бегать по всему файлу в поисках измененных строк. И, наконец, ими легко управлять, хотите выключить – просто закомментировали этот блок, целиком или частично.
Но есть одна небольшая проблема, многие из тех, кто правят собственно конфигурационный файл редко докручивают его до самого конца и поэтому остаются в неведении о существовании альтернативного набора настроек.
Хорошо, с этим разобрались, но как узнать какие именно настройки использует сервер СУБД в текущее время? Довольно просто, достаточно выполнить команду:
psql -U postgres -h 127.0.0.1 -d postgres -c "SHOW min_wal_size;"
Она соединится с локальным экземпляром СУБД и выполнить команду SHOW, которая покажет используемое значение параметра конфигурации, в нашем случае min_wal_size.
Если же мы хотим узнать откуда именно было получено это значение, то придется пойти более сложным путем – выполнить небольшой SQL запрос, это можно сделать как в консоли, но если вы не владеете консольным кун-фу Postgres, то лучше использовать графический инструмент, скажем PgAdmin.
SELECT name, setting, source, sourcefile, sourceline
FROM pg_settings
WHERE name = 'max_wal_size';
Данный запрос выведет не только текущее значение параметра, но и его источник, расположение файла источника и номер строки в нем.
Кстати, источником не обязательно может быть конфигурационный файл, это может быть:
▫️ default - значение по умолчанию, самый низкий приоритет
▫️ configuration file - конфигурационный файл, приоритет выше default
▫️ override - параметр изменен через ALTER SYSTEM, имеет более высокий приоритет
▫️ command line - значение командной строки при запуске, часто используется в Docker, имеет еще более высокий приоритет.
▫️ environment variable - значение из переменных окружения, которые могут быть заданы как глобально, так и на уровне отдельного клиента, приоритет еще выше.
▫️ client - установлен клиентом в рамках сессии, имеет максимальный приоритет, но применяется только в рамках текущей сессии и не влияет на остальные соединения.
Поэтому, если ваш PostgreSQL ведет себя не так как ожидается, то сначала внимательно изучите конфигурационный файл, как самый частый способ внесения изменений. А потом перейдите к более детальной отладке, чтобы точно выяснить какое значение используется в реальности и кто его установил.
