Файл конфигурации postgresql conf содержит ошибки
I want to deploy a simple master-slave pair using the replication options, as well as give it my own custom postgresql.conf file. If I try and give it a config file, it will not create the replication user, the database, or any user specified under POSTGRESQL_USERNAME. If I remove the custom file from the equation, it will create all the users/db as expected. Is there a way to do both via the arguments without having to resort to writing my own sql setup files?
Steps to reproduce the issue:
- Write a basic docker-compose YAML file for the master and the slave. My master file:
- Bring the master and slave up using docker-compose up -d
- Go into the container via bash
- Use psql in /opt/bitnami/postgresql/bin to get into the db with pgsql -U postgres
- Run \l to list databases, see that testdb was not created and only the default postgres ones are present
- Run \du and see that neither testuser or repuser was created - the only user is postgres
Describe the results you received:
The custom config is applied, but neither of the users nor the database specified via the environment variables are created. The slave fails to connect with repuser since it does not exist
Describe the results you expected:
I expected both the custom config to be used AND the users and database to be created, since the data directory is empty and reinitialized on every run. I tested that this issue is also present if I used a permanent storage volume that I cleared after every run.
Additional information you deem important (e.g. issue happens only occasionally):
You can verify that is it the presence of the config file that makes the users/db not be created by either:
- moving the config file out of the mounted volume and re-running
- Removing the volume entirely from the YAML file
In both cases, the users and db will be created as expected, though obviously now there is no custom config applied.
Version
- Output of docker-compose version (if applicable):
Additional environment details (AWS, VirtualBox, Docker for MAC, physical, etc.):
Using the 11-debian-9 image running on an Ubuntu 18.04 base.
Имена всех параметров являются регистронезависимыми. Каждый параметр принимает значение одного из пяти типов: логический, строка, целое, число с плавающей точкой или перечисление. От типа значения зависит синтаксис установки этого параметра:
Логический: Значения могут задаваться строками on , off , true , false , yes , no , 1 , 0 (регистр не имеет значения), либо как достаточно однозначный префикс одной из этих строк.
Строка: Обычно строковое значение заключается в апострофы (при этом внутренние апострофы дублируются). Однако, если значение является простым числом или идентификатором, апострофы обычно можно опустить.
Число (целое или с плавающей точкой): Десятичная точка как разделитель целой и дробной части допускается только для параметров, принимающих числа с плавающей точкой. Разделители разрядов в записи числа не принимаются. Заключать в апострофы число не требуется.
Число с единицей измерения: Некоторые числовые параметры задаются с единицами измерения, так как они описывают количества информации или времени. Единицами могут быть килобайты, блоки (обычно восемь килобайт), миллисекунды, секунды или минуты. При указании только числового значения для такого параметра единицей измерения будет считаться единица по умолчанию для параметра, которая указывается в pg_settings . unit . Для удобства параметры также можно задавать, указывая единицу измерения явно, например, задать '120 ms' для значения времени, при этом такое значение будет переведено в основную единицу измерения параметра. Заметьте, что для этого значение должно записываться в виде строки (в апострофах). Имя единицы является регистронезависимым, а между ним и числом допускаются пробельные символы.
Допустимые единицы информации: kB (килобайты), MB (мегабайты), GB (гигабайты) и TB (терабайты). Множителем единиц информации считается 1024, не 1000.
18.1.2. Определение параметров в файле конфигурации
Самый основной способ установки этих параметров — определение их значений в файле postgresql.conf , который обычно находится в каталоге данных. При инициализации каталога кластера БД в этот каталог помещается копия стандартного файла. Например, он может выглядеть так:
Параметры, установленные таким образом, задают значения по умолчанию для данного кластера. Эти значения будут действовать в активных сеансах, если не будут переопределены. В следующих разделах описывается, как их может переопределить администратор или пользователь.
Основной процесс сервера перечитывает файл конфигурации заново, получая сигнал SIGHUP ; послать его проще всего можно, запустив pg_ctl reload в командной строке или вызвав SQL-функцию pg_reload_conf() . Основной процесс сервера передаёт этот сигнал всем остальным запущенным серверным процессам, так что существующие сеансы тоже получают новые значения (после того, как завершится выполнение текущей команды клиента). Также возможно послать этот сигнал напрямую одному из серверных процессов. Учтите, что некоторые параметры можно установить только при запуске сервера; любые изменения их значений в файле конфигурации не будут учитываться до перезапуска сервера. Более того, при обработке SIGHUP игнорируются неверные значения параметров (но об этом сообщается в журнале).
В дополнение к postgresql.conf в каталоге данных Postgres Pro содержится файл 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 не даёт желаемого эффекта.
Как обновить базу данных PostgreSQL при переходе на новую версию
Оно означает, что в системе 2 установленные версии PostgreSQL:
Если запустить службу PostgreSQL командой:
И проверить версию командой:
То будет выведено следующее:
То есть по умолчанию используется 13, устаревшая версия.
Удаление старых версий пакетов, например, командой:
ситуацию не меняет. Если вам нужно перенести базы данных из устаревшей версии в новую, то верните устаревшие пакеты, если вы успели их удалить.
Последующие действия подразумевают, что вы
1) установили новую версию PostgreSQL, но ещё не использовали её, то есть не сохраняли базы данных, поскольку файлы новой версии будут удалены.
2) хотите перенести старые база данных в новый формат
С помощью следующей команды просмотрите доступные кластеры:
На скриншоте только один из них online (я успел удалить пакет postgresql-13), но у вас оба должны быть online, иначе перенос базы данных не удастся.
Пример правильного вывода:
Как можно увидеть, обе версии 13 и 14 в настоящее время установлены и запущены. Держите в уме, что при переносе старой базы данных в новый формат вам понадобиться двойной объём места на диске, поскольку pg_upgradecluster копирует данные.
Процедура обновления включает в себя следующее:
1. Удаляем данные новой версии:
2. Запускаем процедуру обновления кластера:
3. Когда операция будет завершена, дважды проверьте, что всё работает
4. Удалите старую версию
Это показывает суть обновления кластера. Конечно, в конкретной вашей ситуации могут быть нюансы: другие номера версий, либо другое расположение файлов с базами данных.
Вновь проверяем версию:
Теперь используется 14, то есть самая последняя версия.
18.1.2. Определение параметров в файле конфигурации
Самый основной способ установки этих параметров — определение их значений в файле postgresql.conf , который обычно находится в каталоге данных. При инициализации каталога кластера БД в этот каталог помещается копия стандартного файла. Например, он может выглядеть так:
Параметры, установленные таким образом, задают значения по умолчанию для данного кластера. Эти значения будут действовать в активных сеансах, если не будут переопределены. В следующих разделах описывается, как их может переопределить администратор или пользователь.
Основной процесс сервера перечитывает файл конфигурации заново, получая сигнал SIGHUP ; послать его проще всего можно, запустив pg_ctl reload в командной строке или вызвав SQL-функцию pg_reload_conf() . Основной процесс сервера передаёт этот сигнал всем остальным запущенным серверным процессам, так что существующие сеансы тоже получают новые значения (после того, как завершится выполнение текущей команды клиента). Также возможно послать этот сигнал напрямую одному из серверных процессов. Учтите, что некоторые параметры можно установить только при запуске сервера; любые изменения их значений в файле конфигурации не будут учитываться до перезапуска сервера. Более того, при обработке SIGHUP игнорируются неверные значения параметров (но об этом сообщается в журнале).
В дополнение к postgresql.conf в каталоге данных Postgres Pro содержится файл 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 не даёт желаемого эффекта.
Как подключиться к локальному серверу PostgreSQL
Для подключения к интерактивному терминалу PostgreSQL используется команда psql.
Примеры синтаксиса команд:
Для psql требуется указать имя пользователя и если он не указан, то пересылается имя текущего пользователя системы, который скорее всего отсутствует в базе данных PostgreSQL, что вызывает ошибку. По умолчанию создаётся пользователь postgres, поэтому без дополнительной настройке вы можете подключиться к серверу PostgreSQL следующим образом:
В чём разница между postgres и psql
postgres
postgres - это сервер базы данных PostgreSQL. Чтобы клиентское приложение могло получить доступ к базе данных, оно подключается (по сети или локально) к работающему экземпляру postgres. Затем экземпляр postgres запускает отдельный серверный процесс для обработки соединения.
Один экземпляр postgres всегда управляет данными только одного кластера базы данных. Кластер базы данных — это набор баз данных, который хранится в общей папке файловой системы («область данных»). В системе может работать более одного экземпляра postgres одновременно, если они используют разные области данных и разные порты связи. Когда postgres запускается, ему необходимо знать расположение области данных. Местоположение должно быть указано параметром -D или переменной среды PGDATA; по умолчанию это значение не установлено. Обычно -D или PGDATA указывает непосредственно на каталог области данных, созданный initdb.
Чтобы запустить сервер в однопользовательском режиме, используйте такую команду, как
Чтобы запустить postgres в фоновом режиме со значениями по умолчанию, введите:
Чтобы запустить postgres с определенным портом, например, 1234:
Чтобы подключиться к этому серверу с помощью psql, укажите этот порт с параметром -p:
или установите переменную окружения PGPORT:
psql
psql — это интерфейс для PostgreSQL на основе терминала. Он позволяет вам вводить запросы в интерактивном режиме, отправлять их в PostgreSQL и просматривать результаты запросов. В качестве альтернативы ввод может быть из файла или из аргументов командной строки. Кроме того, psql предоставляет ряд мета-команд и различных функций, подобных оболочке, для облегчения написания сценариев и автоматизации широкого спектра задач.
Пример запуска psql:
Запуск psql от пользователя postgres, который создаётся по умолчанию:
18.1.4. Управление параметрами в командной строке
Помимо изменения глобальных значений по умолчанию и переопределения их на уровне базы данных или роли, параметры Postgres Pro можно изменить, используя средства командной строки. Управление через командную строку поддерживают и сервер, и клиентская библиотека libpq .
При запуске сервера, значения параметров можно передать команде postgres в аргументе командной строки -c . Например:
Параметры, заданные таким образом, переопределяют те, что были установлены в postgresql.conf или командой ALTER SYSTEM , так что их нельзя изменить глобально без перезапуска сервера.
При запуске клиентского сеанса, использующего libpq , значения параметров можно указать в переменной окружения PGOPTIONS . Заданные таким образом параметры будут определять значения по умолчанию на время сеанса, но никак не влияют на другие сеансы. По историческим причинам формат PGOPTIONS похож на тот, что применяется при запуске команды postgres ; в частности, в нём должен присутствовать флаг -c . Например:
FATAL: не удалось создать файл блокировки "/run/postgresql/.s.PGSQL.5432.lock": Нет такого файла или каталога
При запуске системы БД, например, следующей командой:
Вы можете столкнуться с ошибкой:
В англоязычной версии ошибка выглядит так:
- Создать данную директорию (если она отсутствует) и сделать её владельцем пользователя postgres
- Отредактировать конфигурационный файл так, чтобы служба пыталась создавать файл блокировки в директории /tmp, на которую у всех пользователей есть право записи
Первый вариант — создаём директорию /run/postgresql/ и назначаем её владельцем пользователя postgres:
Второй вариант — открываем конфигурационный файл postgresql.conf (у вас может быть другое расположение)
И добавляем туда следующую запись:
Ошибки PostgreSQL
Как инициализировать базу данных PostgreSQL
Остановите службу, если она запущена:
Директория /var/lib/postgres/ должна принадлежать пользователю postgres:
Смените пользователя на postgres:
Выполните инициализацию БД:
Если вы столкнулись с ошибкой:
То найдите расположение файла initdb:
И укажите до него полный путь в команде инициализации:
Нажмите CTRL+D
Запустите службу PostgreSQL:
Создайте нового пользователя (например, user):
При желании, вы можете установить пароль для пользователя, это делается командой с ключом -W:
Создайте базу данных (например, my-first-db):
18.1.3. Управление параметрами через SQL
В Postgres Pro есть три SQL-команды, задающие для параметров значения по умолчанию. Уже упомянутая команда ALTER SYSTEM даёт возможность изменять глобальные значения средствами SQL; она функционально равнозначна редактированию postgresql.conf . Кроме того, есть ещё две команды, которые позволяют задавать значения по умолчанию на уровне баз данных и ролей:
Команда ALTER DATABASE позволяет переопределить глобальные параметры на уровне базы данных.
Значения, установленные командами ALTER DATABASE и ALTER ROLE , применяются только при новом подключении к базе данных. Они переопределяют значения, полученные из файлов конфигурации или командной строки сервера, и применяются по умолчанию в рамках сеанса. Заметьте, что некоторые параметры невозможно изменить после запуска сервера, поэтому их нельзя установить этими командами (или командами, перечисленными ниже).
Когда клиент подключён к базе данных, он может воспользоваться двумя дополнительными командами SQL (и равнозначными функциями), которые предоставляет Postgres Pro для управления параметрами конфигурации:
Команда SHOW позволяет узнать текущее значение всех параметров. Соответствующая ей функция — current_setting(имя_параметра text) .
Кроме того, просмотреть и изменить значения параметров для текущего сеанса можно в системном представлении pg_settings :
Запрос на чтение представления выдаёт ту же информацию, что и SHOW ALL , но более подробно. Этот подход и более гибкий, так как в нём можно указать условия фильтра или связать результат с другими отношениями.
Выполнение UPDATE для этого представления, а именно присвоение значения столбцу, равносильно выполнению команды SET . Например, команде
Вы должны указать его расположение в параметре --config-file или -D, либо установить переменную окружения PGDATA
При запуске postgres вы можете столкнуться с ошибкой:
В англоязычной версии:
Суть ошибки в том, что необходимо указать конфигурационный файл в опции командной строки или в переменной окружения. Как вариант — можно указать путь до базы данных, содержащий конфигурационный файл. Например:
Конфигурационный файл называется postgresql.conf, но нужно указать не его, а директорию, в которой он содержится. Например:
19.1.4. Управление параметрами в командной строке
Помимо изменения глобальных значений по умолчанию и переопределения их на уровне базы данных или роли, параметры PostgreSQL можно изменить, используя средства командной строки. Управление через командную строку поддерживают и сервер, и клиентская библиотека libpq .
При запуске сервера, значения параметров можно передать команде postgres в аргументе командной строки -c . Например:
Параметры, заданные таким образом, переопределяют те, что были установлены в postgresql.conf или командой ALTER SYSTEM , так что их нельзя изменить глобально без перезапуска сервера.
При запуске клиентского сеанса, использующего libpq , значения параметров можно указать в переменной окружения PGOPTIONS . Заданные таким образом параметры будут определять значения по умолчанию на время сеанса, но никак не влияют на другие сеансы. По историческим причинам формат PGOPTIONS похож на тот, что применяется при запуске команды postgres ; в частности, в нём должен присутствовать флаг -c . Например:
psql: ошибка: ВАЖНО: роль "" не существует
При попытке запуска интерактивного терминала PostgreSQL
Вы можете столкнуться с ошибкой:
Имя пользователя может быть другим — там будет показано имя того пользователя, котоырй пытается выполнить вход.
В англоязычной версии ошибка выглядит так:
Для psql необходимо имя пользователя и если оно не указано явно, то передаётся имя пользователя системы. Но поскольку данный пользователь не существует на сервере PostgreSQL, то возникает указанная выше ошибка.
Вы можете создать пользователя с любы именем, как это показано выше и ошибка исчезнет.
По умолчанию присутствует пользователь postgres, поэтому вы можете подключиться от его имени:
Использование PostgreSQL
Какой конфигурационный файл использует PostgreSQL
Конфигурационный файл PostgreSQL носит имя postgresql.conf.
В системе может быть несколько конфигурационных файлов PostgreSQL. Вы можете найти их командой:
Что особенно важно, systemd может использовать свои собственные конфигурационные файлы, например:
- /usr/lib/systemd/system/postgresql@.service.d/kali_postgresql.conf (путь в Kali Linux)
- /usr/lib/sysusers.d/postgresql.conf (путь в Arch Linux)
Если вы настраиваете PostgreSQL, но после перезапуска службы с помощью systemd (systemctl) изменения не применяются, возможно, вы просто редактируете неверный файл.
Также конфигурационный файл имеется в директории с базой данных, например:
- /var/lib/postgres/data/postgresql.conf
С пакетом PostgreSQL могут поставляться образцы конфигурационных файлов, например:
- /usr/share/postgresql/14/postgresql.conf.sample
- /usr/share/postgresql/postgresql.conf.sample
19.1.3. Управление параметрами через SQL
В PostgreSQL есть три SQL-команды, задающие для параметров значения по умолчанию. Уже упомянутая команда ALTER SYSTEM даёт возможность изменять глобальные значения средствами SQL; она функционально равнозначна редактированию postgresql.conf . Кроме того, есть ещё две команды, которые позволяют задавать значения по умолчанию на уровне баз данных и ролей:
Команда ALTER DATABASE позволяет переопределить глобальные параметры на уровне базы данных.
Значения, установленные командами ALTER DATABASE и ALTER ROLE , применяются только при новом подключении к базе данных. Они переопределяют значения, полученные из файлов конфигурации или командной строки сервера, и применяются по умолчанию в рамках сеанса. Заметьте, что некоторые параметры невозможно изменить после запуска сервера, поэтому их нельзя установить этими командами (или командами, перечисленными ниже).
Когда клиент подключён к базе данных, он может воспользоваться двумя дополнительными командами SQL (и равнозначными функциями), которые предоставляет PostgreSQL для управления параметрами конфигурации:
Команда SHOW позволяет узнать текущее значение всех параметров. Соответствующая ей функция — current_setting(имя_параметра text) .
Кроме того, просмотреть и изменить значения параметров для текущего сеанса можно в системном представлении pg_settings :
Запрос на чтение представления выдаёт ту же информацию, что и SHOW ALL , но более подробно. Этот подход и более гибкий, так как в нём можно указать условия фильтра или связать результат с другими отношениями.
Выполнение UPDATE для этого представления, а именно присваивание значения столбцу setting , равносильно выполнению команды SET . Например, команде
psql: error: не удалось подключиться к серверу: Нет такого файла или каталога
При попытке подключиться к серверу PostgreSQL или выполнить запрос на сервере PostgreSQL, например:
вы можете столкнуться с ошибкой:
В англоязычной версии эта ошибка выглядит так:
Эта ошибка означает, что служба PostgreSQL не запущена, для её запуска выполните команду:
Альтернативный вариант запуска службы следующий:
Другой возможной причиной ошибки может быть то, что psql ищет файл сокета в неверной директории: например, файл сокета помещён в /tmp, а psql ищет его в /run/postgresql/. В этом случае вы можете с помощью опции --host явно указать директорию, в которой находится сокет:
sudo: postgres: command not found
Если при использовании postgres вы столкнулись с ошибкой:
то у этой проблемы может быть две возможных причины:
1. Не установлен пакет postgresql.
Установите его одной из следующих команд.
В Debian, Kali Linux, Linux Mint, Ubuntu и их производных:
В Arch Linux, Manjaro, BlackArch и их производных:
2. Исполнимый файл postgres находится за пределами $PATH
Это необязательно говорит о проблеме — такой подход может использоваться для возможности иметь на одном компьютере сразу несколько серверов PostgreSQL.
Найдите исполнимый файл
Как можно видеть на скриншоте, исполнимый файл присутствует для двух версий сервера:
- /usr/lib/postgresql/13/bin/postgres
- /usr/lib/postgresql/14/bin/postgres
Теперь вместо postgres используйте полный путь в команде запуска, например:
Как запустить службу PostgreSQL. Как управлять службой PostgreSQL
Запуск службы PostgreSQL:
Остановка службы PostgreSQL:
Добавление службы PostgreSQL в автозагрузку:
Удаление службы PostgreSQL из автозагрузки:
Для просмотра состояния процесса PostgreSQL:
Альтернативный вариант запуска службы для работы с определённой базой данных следующий:
18.1.5. Упорядочение содержимого файлов конфигурации
Postgres Pro предоставляет несколько возможностей для разделения сложных файлов postgresql.conf на вложенные файлы. Эти возможности особенно полезны при управлении множеством серверов с похожими, но не одинаковыми конфигурациями.
Помимо присвоений значений параметров, postgresql.conf может содержать директивы включения файлов, которые будут прочитаны и обработаны, как если бы их содержимое было вставлено в данном месте файла конфигурации. Это позволяет разбивать файл конфигурации на физически отдельные части. Директивы включения записываются просто:
Если имя файла задаётся не абсолютным путём, оно рассматривается относительно каталога, в котором находится включающий файл конфигурации. Включения файлов могут быть вложенными.
Файл postgresql.conf может также содержать директивы include_dir , позволяющие подключать целые каталоги с файлами конфигурации. Они записываются так:
Имена, заданные не абсолютным путём, рассматриваются относительно каталога, содержащего текущий файл конфигурации. В заданном каталоге включению подлежат только файлы с именами, оканчивающимися на .conf . При этом файлы с именами, начинающимися с « . », тоже игнорируются, для предотвращения ошибок, так как они считаются скрытыми в ряде систем. Набор файлов во включаемом каталоге обрабатывается по порядку имён (определяемому правилами, принятыми в C, т. е. цифры идут перед буквами, а буквы в верхнем регистре — перед буквами в нижнем).
Включение файлов или каталогов позволяет разделить конфигурацию базы данных на логические части, а не вести один большой файл postgresql.conf . Например, представьте, что в некоторой компании есть два сервера баз данных, с разным объёмом ОЗУ. Скорее всего при этом их конфигурации будут иметь общие элементы, например, параметры ведения журналов. Но параметры, связанные с памятью, у них будут различаться. Кроме того, другие параметры могут быть специфическими для каждого сервера. Один из вариантов эффективного управления такими конфигурациями — разделить изменения стандартной конфигурации на три файла. Чтобы подключить эти файлы, можно добавить в конец файла postgresql.conf следующие директивы:
Общие для всех серверов параметры будут помещаться в shared.conf . Файл memory.conf может иметь два варианта — первый для серверов с 8ГБ ОЗУ, а второй для серверов с 16 ГБ. Наконец, server.conf может содержать действительно специфические параметры для каждого отдельного сервера.
Также возможно создать каталог с файлами конфигурации и поместить туда все эти файлы. Например, так можно подключить каталог conf.d в конце postgresql.conf :
Затем можно дать файлам в каталоге conf.d следующие имена:
Такое именование устанавливает чёткий порядок подключения этих файлов, что важно, так как если параметр определяется несколько раз в разных файлах конфигурации, действовать будет последнее определение. В рамках данного примера, установленное в conf.d/02server.conf значение переопределит значение того же параметра, заданное в conf.d/01memory.conf .
Вы можете применить этот подход и с описательными именами файлов:
При таком упорядочивании каждому варианту файла конфигурации даётся уникальное имя. Это помогает исключить конфликты, если конфигурации разных серверов нужно хранить в одном месте, например, в репозитории системы управления версиями. (Кстати, хранение файлов конфигурации в системе управления версиями — это ещё один эффективный приём, который стоит применять.)
Which is the quickest way to troubleshot the message "
I made a couple of changes a few days ago, and did not reload Today I made some more changes and did a pg_ctl reload.
Is there an option to test the configuration file for errors, after making changes?
Thanks. This is what I have. May be it is not really an error?
2013-10-18 12:23:54.996 IST. 8855,,523c23ea.2297,20,,2013-09-20 16:01:06 IST,,0,LOG,00000,"received SIGHUP, reloading configuration files". ""
2013-10-18 12:23:54.996 IST. 8855,,523c23ea.2297,21,,2013-09-20 16:01:06 IST,,0,LOG,55P02,"parameter ""superuser_reserved_connections"" cannot be changed without restarting the server". ""
2013-10-18 12:23:54.997 IST. 8855,,523c23ea.2297,22,,2013-09-20 16:01:06 IST,,0,LOG,F0000,"configuration file ""/pgdata/prod/data_93/postgresql.conf"" contains errors; unaffected changes were applied". ""
Jayadevan M > writes:
> Which is the quickest way to troubleshot the message "
> LOG: configuration file ". /postgresql.conf" contains errors;
> unaffected changes were applied"" ?
There should be log message(s) before that one complaining about the
specific problems.
Thanks. This is what I have. May be it is not really an error?
2013-10-18 12:23:54.996 IST. 8855,,523c23ea.2297,20,,2013-09-20 16:01:06 IST,,0,LOG,00000,"received SIGHUP, reloading configuration files". ""
2013-10-18 12:23:54.996 IST. 8855,,523c23ea.2297,21,,2013-09-20 16:01:06 IST,,0,LOG,55P02,"parameter ""superuser_reserved_connections"" cannot be changed without restarting the server". ""
2013-10-18 12:23:54.997 IST. 8855,,523c23ea.2297,22,,2013-09-20 16:01:06 IST,,0,LOG,F0000,"configuration file ""/pgdata/prod/data_93/postgresql.conf"" contains errors; unaffected changes were applied". ""
To effect new changes related to "superuser_reserved_connections" parameters in Postgresql.conf file requires RESTART of the PostgreSQL Service.
Имена всех параметров являются регистронезависимыми. Каждый параметр принимает значение одного из пяти типов: логический, строка, целое, число с плавающей точкой или перечисление. От типа значения зависит синтаксис установки этого параметра:
Логический: Значения могут задаваться строками on , off , true , false , yes , no , 1 , 0 (регистр не имеет значения), либо как достаточно однозначный префикс одной из этих строк.
Строка: Обычно строковое значение заключается в апострофы (при этом внутренние апострофы дублируются). Однако если значение является простым числом или идентификатором, апострофы обычно можно опустить. (Значения, совпадающие с ключевыми словами SQL, всё же требуют заключения в апострофы в некоторых контекстах.)
Число (целое или с плавающей точкой): Значения числовых параметров могут задаваться в обычных форматах, принятых для целых чисел или чисел с плавающей точкой; если параметр целочисленный, дробные значения округляются до ближайшего целого. Кроме того, целочисленные параметры принимают значения в шестнадцатеричном (с префиксом 0x ) и восьмеричном (с префиксом 0 ) виде, но дробная часть в таких случаях исключена. Разделители разрядов в значениях использовать нельзя. Заключать в кавычки требуется только значения в шестнадцатеричном виде.
Число с единицей измерения: Некоторые числовые параметры задаются с единицами измерения, так как они описывают количества информации или времени. Единицами могут быть байты, килобайты, блоки (обычно восемь килобайт), миллисекунды, секунды или минуты. При указании только числового значения для такого параметра единицей измерения будет считаться установленная для него единица по умолчанию, которая указывается в pg_settings . unit . Для удобства параметры также можно задавать, указывая единицу измерения явно, например, задать '120 ms' для значения времени. При этом такое значение будет переведено в основную единицу измерения параметра. Заметьте, что для этого значение должно записываться в виде строки (в апострофах). Имя единицы является регистронезависимым, а между ним и числом допускаются пробельные символы.
Допустимые единицы информации: B (байты), kB (килобайты), MB (мегабайты), GB (гигабайты) и TB (терабайты). Множителем единиц информации считается 1024, не 1000.
Если с единицей измерения задаётся дробное значение, оно будет округлено до следующей меньшей единицы, если такая имеется. Например, значение 30.1 GB будет преобразовано в 30822 MB , а не в 32319628902 B . Если параметр имеет целочисленный тип, после преобразования единиц измерения значение окончательно округляется до целого.
19.1.2. Определение параметров в файле конфигурации
Самый основной способ установки этих параметров — определение их значений в файле postgresql.conf , который обычно находится в каталоге данных. При инициализации каталога кластера БД в этот каталог помещается копия стандартного файла. Например, он может выглядеть так:
Параметры, установленные таким образом, задают значения по умолчанию для данного кластера. Эти значения будут действовать в активных сеансах, если не будут переопределены. В следующих разделах описывается, как их может переопределить администратор или пользователь.
Основной процесс сервера перечитывает файл конфигурации заново, получая сигнал SIGHUP ; послать его проще всего можно, запустив pg_ctl reload в командной строке или вызвав SQL-функцию pg_reload_conf() . Основной процесс сервера передаёт этот сигнал всем остальным запущенным серверным процессам, так что существующие сеансы тоже получают новые значения (после того, как завершится выполнение текущей команды клиента). Также возможно послать этот сигнал напрямую одному из серверных процессов. Учтите, что некоторые параметры можно установить только при запуске сервера; любые изменения их значений в файле конфигурации не будут учитываться до перезапуска сервера. Более того, при обработке SIGHUP игнорируются неверные значения параметров (но об этом сообщается в журнале).
В дополнение к postgresql.conf в каталоге данных PostgreSQL содержится файл 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 не даёт желаемого эффекта.
initdb: command not found
Смотрите объяснение данной проблемы, а также дополнительные пути устранения в описании аналогичной ошибки: sudo: postgres: command not found
Найдите initdb с помощью:
- /usr/lib/postgresql/13/bin/initdb
- /usr/lib/postgresql/14/bin/initdb
И используйте в ваших командах абсолютный путь до файла initdb нужной вам версии, например:
Как узнать, какая версия PostgreSQL запущена
Версию запущенной PostgreSQL не всегда можно определить по установленным пакетам. Например, во время обновления PostgreSQL на некоторых дистрибутивах не заменяет предыдущую версию, а устанавливает новую в дополнении к имеющейся. Иногда у пользователя в корпоративной среде есть доступ через Navicat или phpPgAdmin, но нет доступа к консоли сервера, на котором работает база данных.
Для определения версии сервера выполните команду:
Для определения версии клиента:
Ещё один вариант определения версии PostgreSQL:
Если вам нужен только номер версии (например, для скрипта), то используйте следующую команду:
Хотя вместо postgres можно использовать postmaster, использование postgres предпочтительнее, поскольку postmaster это устаревший псевдоним для postgres.
Если вы предпочитаете вариант с SQL, то подключитесь к интерактивному терминалу:
Также вам может пригодиться один из следующих вариантов
19.1.5. Упорядочение содержимого файлов конфигурации
PostgreSQL предоставляет несколько возможностей для разделения сложных файлов postgresql.conf на вложенные файлы. Эти возможности особенно полезны при управлении множеством серверов с похожими, но не одинаковыми конфигурациями.
Помимо присваиваний значений параметров, postgresql.conf может содержать директивы включения файлов, которые будут прочитаны и обработаны, как если бы их содержимое было вставлено в данном месте файла конфигурации. Это позволяет разбивать файл конфигурации на физически отдельные части. Директивы включения записываются просто:
Если имя файла задаётся не абсолютным путём, оно рассматривается относительно каталога, в котором находится включающий файл конфигурации. Включения файлов могут быть вложенными.
Файл postgresql.conf может также содержать директивы include_dir , позволяющие подключать целые каталоги с файлами конфигурации. Они записываются так:
Имена, заданные не абсолютным путём, рассматриваются относительно каталога, содержащего текущий файл конфигурации. В заданном каталоге включению подлежат только файлы с именами, оканчивающимися на .conf . При этом файлы с именами, начинающимися с « . », тоже игнорируются, для предотвращения ошибок, так как они считаются скрытыми в ряде систем. Набор файлов во включаемом каталоге обрабатывается по порядку имён (определяемому правилами, принятыми в C, т. е. цифры идут перед буквами, а буквы в верхнем регистре — перед буквами в нижнем).
Включение файлов или каталогов позволяет разделить конфигурацию базы данных на логические части, а не вести один большой файл postgresql.conf . Например, представьте, что в некоторой компании есть два сервера баз данных, с разным объёмом ОЗУ. Скорее всего при этом их конфигурации будут иметь общие элементы, например, параметры ведения журналов. Но параметры, связанные с памятью, у них будут различаться. Кроме того, другие параметры могут быть специфическими для каждого сервера. Один из вариантов эффективного управления такими конфигурациями — разделить изменения стандартной конфигурации на три файла. Чтобы подключить эти файлы, можно добавить в конец файла postgresql.conf следующие директивы:
Общие для всех серверов параметры будут помещаться в shared.conf . Файл memory.conf может иметь два варианта — первый для серверов с 8ГБ ОЗУ, а второй для серверов с 16 ГБ. Наконец, server.conf может содержать действительно специфические параметры для каждого отдельного сервера.
Также возможно создать каталог с файлами конфигурации и поместить туда все эти файлы. Например, так можно подключить каталог conf.d в конце postgresql.conf :
Затем можно дать файлам в каталоге conf.d следующие имена:
Такое именование устанавливает чёткий порядок подключения этих файлов, что важно, так как если параметр определяется несколько раз в разных файлах конфигурации, действовать будет последнее определение. В рамках данного примера, установленное в conf.d/02server.conf значение переопределит значение того же параметра, заданное в conf.d/01memory.conf .
Вы можете применить этот подход и с описательными именами файлов:
При таком упорядочивании каждому варианту файла конфигурации даётся уникальное имя. Это помогает исключить конфликты, если конфигурации разных серверов нужно хранить в одном месте, например, в репозитории системы управления версиями. (Кстати, хранение файлов конфигурации в системе управления версиями — это ещё один эффективный приём, который стоит применять.)
PostgreSQL, как сказано на её официальном сайте, это самая продвинутая в мире реляционная база данных с открытым исходным кодом.
Читайте также: