PostgreSQL/Краткое руководство
Эта статья представляет собой краткое руководство по установке и настройке PostgreSQL. Это руководство является дополнением к официальной документации; оно не призвано заменить ее.
Введение
PostgreSQL — это свободная система управления реляционными базами данных (RDBMS, или СУРБД) с открытым исходным кодом. Она поддерживает такие вещи, как транзакции, схемы и внешние ключи, и часто позиционируется как более строго соответствующая стандартам SQL и более безопасная по умолчанию, чем любая другая база данных, коммерческая или нет.
Посетите страницу About на postgresql.org для более подробной информации.
Что охватывает эта статья?
Эта статья проведет вас через специфичные для Gentoo шаги по установке СУРБД PostgreSQL.
Ebuild-файл, охватываемый этой статьей: dev-db/postgresql.
В этой статье предполагается, что вы будете устанавливать последнюю, стабильную версию PostgreSQL; на время написания, этой версией является 9.3.5. Исправьте команды в этой статье так, как это требуется для вашей определенной версии.
О ebuild-файлах
Файлы ebuild для PostgreSQL в системе Portage отличаются номерами слотов, основанными на главной версии. Это позволяет вам иметь две главных версии PostgreSQL действующих одновременно; библиотеки и сервера версий 9.0-9.4 могут устанавливаться и обслуживаться в одно и то же время. Это полезно в тех обстоятельствах, когда вам нужно перенести данные из старой базы данных в новую, или требуется иметь рабочую и тестовую базу данных на одной и той же машине. Также, это предотвращает перезаписывание баз данных, соответствующих библиотек или исполняемых файлов несовместимым обновлением. Это требует миграции, которая описана в данном руководстве.
Вдобавок, исправления ошибок и уязвимостей безопасности, которые поставляются через обновления младших версий, могут применяться без страха повреждения базы данных или самой сборки PostgreSQL; 9.3.4 может обновляться до 9.3.5, так как гарантируется их совместимость и они не требуют от вас большего, чем установка и перезапуск серверного процесса. Ни миграция, ни повторная конфигурация, ни инициализация не являются необходимыми.
За подробностями обратитесь к PostgreSQL Versioning Policy.
Что эта статья не охватывает
Большая часть информации не будет описана. Официальная документация содержит где-то 2000 страниц. Поэтому в этом кратком руководстве большинство подробностей будет пропущено. Будут описаны только проблемы, характерные для Gentoo, и некоторые основные рекомендации по конфигурации.
Установка
USE-флаги
USE flags for dev-db/postgresql PostgreSQL RDBMS
+icu
|
Enable ICU (Internationalization Components for Unicode) support, using dev-libs/icu |
+lz4
|
Enable support for lz4 compression (as implemented in app-arch/lz4) |
+readline
|
Enable support for libreadline, a GNU line-editing library that almost everyone wants |
+server
|
Disable to build and install the clients and libraries only. |
+zstd
|
Enable support for ZSTD compression |
debug
|
Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces |
doc
|
Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally |
kerberos
|
Add kerberos support |
ldap
|
Add LDAP support (Lightweight Directory Access Protocol) |
llvm
|
Add support for llvm JIT engine |
nls
|
Add Native Language Support (using gettext - GNU locale utilities) |
pam
|
Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip |
perl
|
Add optional support/bindings for the Perl language |
python
|
Add optional support/bindings for the Python language |
selinux
|
!!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur |
ssl
|
Add support for SSL/TLS connections (Secure Socket Layer / Transport Layer Security) |
static-libs
|
Build static versions of dynamic libraries as well |
systemd
|
Enable use of systemd-specific libraries and features like socket activation or session tracking |
tcl
|
Add support the Tcl language |
test
|
Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently) |
uuid
|
Enable server side UUID generation (via dev-libs/ossp-uuid). |
xml
|
Add support for XML files |
zlib
|
Add support for zlib compression |
Информация о соответствующих USE-флагах:
- doc: Включает онлайн документацию, которая будет храниться в вашей системе.
- pg_legacytimestamp: Используется старый метод для форматирования временных меток с плавающей точкой вместо целочисленного 64-битного метода высокого разрешения. Если вы в прошлой инсталляции удалили этот метод, оставьте этот USE-флаг отключенным. 'pg_legacytimestamp' потребуется вам для дампа и восстановления в случае, если любая из ваших баз данных очистила временные метки. Два метода несовместимы.
- readline: Вы наверняка захотите включить его. Отключение упразднит историю и редактирование в командной строке psql.
- selinux: Может быть включен только вместе с профилем SELinux.
- uuid: Включает поддержку генерации 128-битного случайного уникального идентификатора. Это полезно при объединении баз данных так, что шансы возникновения коллизий крайне низки.
Установка
root #
emerge --ask dev-db/postgresql
[ebuild N ] dev-db/postgresql-9.3.5 USE="doc -kerberos -ldap -pg_legacytimestamp nls perl python -pg_legacytimestamp (-selinux) readline ssl -tcl -threads -uuid -xml zlib" LINGUAS="-af -cs -de -es -fa -fr -hr -hu -it -ko -nb -pl -pt_BR -ro -ru -sk -sl -sv -tr -zh_CN -zh_TW" 0 kB
Вы можете получить уведомление о том, что какие-либо из вышеперечисленных пакетов заблокированы одним или всеми из следующих пакетов: dev-db/postgresql-libs, dev-db/postgresql-client или dev-db/libpq. Эти пакеты являлись не поддерживаемыми и устаревшими (удалены из ebuild–репозитория Gentoo). Обратитесь к разделу по миграции с предыдущих ebuild-файлов к новым, чтобы узнать, как разрешить эту проблему.
Подготовка к инициализации кластера баз данных
Как только пакеты завершили установку, вы можете пожелать отредактировать /etc/conf.d/postgresql-9.3. Существуют три строки, которые затрагивают значения сервера по умолчанию и не могут быть изменены позже без удаления каталога, который содержит кластер базы данных, и повторной инициализации.
PGDATA определяет где размещать файлы настроек. DATA_DIR определяет где создавать кластер базы данных и сопутствующие файлы. PG_INITDB_OPTS может хранить любые дополнительные параметры, которые вы можете пожелать установить. Установка дополнительных параметров не требуется, так как разумные значения по умолчанию, кхм, разумны.
В следующем примере, PGDATA определяет что файлы настроек должны быть расположены в /etc/postgresql-9.3/. DATA_DIR определяет, что кластер базы данных должен быть установлен в /var/lib/postgresql/9.3/data/, который является каталогом по умолчанию. Если вы решите отказаться от значений по умолчанию, помните, что очень хорошей идеей будет хранить номер старшей версии в переменной PATH. PG_INITDB_OPTS определяет, что локалью по умолчанию должна быть en_US.UTF-8. То есть, будет использоваться английское упорядочивание и форматирование, и кодировка символов UTF-8.
# Размещение файлов конфигурации
PGDATA="/etc/postgresql-9.3/"
# Где размещается/должен быть создан каталог с данными
DATA_DIR="/var/lib/postgresql/9.3/data"
# Дополнительные параметры для передачи в initdb.
# Смотрите 'man initdb', чтобы узнать доступные параметры.
PG_INITDB_OPTS="--locale=en_US.UTF-8"
Это только определяет локаль и кодировку символов по умолчанию. Вы можете указать разные локали и/или кодировки символов во время создания базы данных (
CREATE DATABASE
) в одном и том же кластере базы данных.Существуют шесть параметров локали, которые могут быть установлены для переопределения --locale=. В следующей таблица показаны шесть таких параметров, которые, если используются, должны быть отформатированы как: --option=lo_LO.ENCODING
.
Параметр | Действия |
---|---|
lc-collate | Порядок сортировки строк |
lc-ctype | Классификация символов (Что является буквой? Ее эквивалент в верхнем регистре?) |
lc-messages | Язык сообщений |
lc-monetary | Форматирование количеств денежных сумм |
lc-numeric | Форматирование чисел |
lc-time | Форматирование даты и времени |
Таким образом, если вы хотите в качестве языка по умолчанию взять английский, но сообщения должны быть на русском, то PG_INITDB_OPTS будут выглядеть так:
PG_INITDB_OPTS="--locale=en_US.UTF-8 --lc-messages=sv_SE.UTF-8"
Полный список языков и кодировок символов, поддерживаемых сервером, может быть найден в документации, но и ваша система также должна поддерживать соответственные языки и кодировки символов. Сравните вывод locale -a
с кодировками в документации.
Вы можете изменить локаль и набор кодировок во время создания базы данных. Для того, чтобы изменить локаль для базы данных после того, как вы ее создали, вам нужно удалить базу данных и начать все сначала.
root #
emerge --config dev-db/postgresql:9.3
Это создаст кластер базы данных и сохранит все принадлежащие серверу файлы в PGDATA и DATA_DIR.
Конфигурация
Где размещаются файлы конфигурации
Sample configuration files can be found in /usr/share/postgresql-9.3 (or whatever version), see the trouble shooting section for the script.
На этот раз мы сосредоточимся на файлах в каталоге PGDATA, /etc/postgresql-9.3, с основным фокусом на файлах postgresql.conf и pg_hba.conf.
postgresql.conf
Это основной файл конфигурации. Строкой, которая немедленно может вас заинтересовать, является listen-addresses. Эта переменная определяет к каким адресам PostgreSQL будет осуществлять привязку. По умолчанию, привязаны только localhost и доменный сокет Unix. Изменения listen_addresses недостаточно для разрешения удаленных соединений. Это будет описано в следующем разделе. Официальная документация довольно легка для понимания и всесторонне охватывает все доступные настройки. Вам следует прочесть ее в дополнение к тому что описано здесь, так как некоторые вещи могут измениться.
Второстепенным вопросом является место назначения логирования. По умолчанию, все пишется в postmaster.log в каталоге DATA_DIR. Имеется целый подраздел postgresql.conf, который охватывает большое количество вариантов того как, что и куда нужно логировать. Подраздел обозначен как: ERROR REPORTING AND LOGGING.
Кроме listen_addresses и параметров логирования, остальная часть значений по умолчанию в postgresql.conf довольно приемлема для начала.
pg_hba.conf
Файл pg_hba.conf определяет кому разрешается подключаться к серверу баз данных и какой метод аутентификации должен быть использован для установки соединения. Опять же, документация по настройкам и тому, что они означают, является довольно исчерпывающей, но несколько вещей здесь описаны для разъяснения.
# TYPE DATABASE USER CIDR-ADDRESS METHOD
# "local" - только для соединений с доменного сокета Unix
local all all trust
# локальные соединения IPv4:
host all all 127.0.0.1/32 trust
# Локальные соединения IPv6:
host all all ::1/128 trust
Как было упомянуто ранее, сервер по умолчанию сконфигурирован безопасно. В своем роде. Существует только одна роль базы данных, которая доступна для входа по умолчанию: postgres. И только одним способом инициировать соединение к базе данных является соединение через сокет Unix /run/postgresql/.s.PGSQL.5432, который принадлежит системному пользователю и группе postgres, или установка соединения через localhost. Теперь вернемся к в своем роде. Любой пользователь системы может подсоединиться к базе данных через localhost. Даже в качестве суперпользователя базы данных postgres.
Никогда не отключайте сокет Unix полностью. Init-скрипту требуется доступ к нему, чтобы функционировать должным образом. Этот метод может быть свободно изменен.
Метод trust — это то, что позволяет любому пользователю входить от имени любого пользователя без пароля. Он обозначает только то, что он подразумевает: доверять всем соединениям для определенного типа к определенной базе данных от определенного пользователя базы данных (но не системного пользователя) из определенного местонахождения без пароля. Это то, что изначально позволяет любому пользователю системы входить от имени любого пользователя через соединение localhost. Это не настолько опасно, как кажется, но представляет серьезный риск для безопасности в большинстве обстоятельств.
Два метода, которые вы наиболее вероятно будете использовать, это password и md5. Метод password только указывает, что для установления соединения требуется пароль и пароль отправляется в виде простого текста. Этот метод хорош тогда, когда такого рода информация никогда не покинет машину, как, например, при соединении через доменный сокет Unix или localhost. Метод md5 схож с password, но защищает пароль использованием хэша md5. Это то, что вам потребуется использовать, когда бы пароль ни был отправлен через сеть.
В данный момент автор хотел бы обратить ваше внимание на последние две строчки и четыре строчки, включающие комментарии, в файле pg_hba.conf. PostgreSQL имеет нативную поддержку IPv6, независимо от того, желаете ли вы такую поддержку или нет. Вдобавок, адреса IPv4 автоматически отображаются в адреса IPv6, т.е., 127.0.0.1 будет отображен в ::FFFF:127.0.0.1 и, как чистый IPv6, ::FFFF:7F00:0001.
Хотя, кажется, есть некоторое непонимание того как имена хостов отображаются в IP-адреса. Давайте рассмотрим файл /etc/hosts.
# Псевдонимы localhost для IPv4 and IPv6
127.0.0.1 localhost
::1 localhost
Из примера выше вы можете видеть, что оба адреса IPv4 и IPv6 отображаются на localhost. Когда psql
обратится к этому файлу, она захватит первое совпадение и использует его в качестве адреса; в этом случае 127.0.0.1. Когда Postgresql его проанализирует, он также будет соответствовать адресу в формате IPv6, например, ::ffff:127.0.0.1. Если, однако же, адрес IPv6 появится первым, то тогда psql
отобразит его только в один ::1; ::1 — это не то же самое, что ::ffff:127.0.0.1. Таким образом, если вы не имеете ::1 в качестве разрешенных средств доступа, psql
не будет способна установить соединение. Кроме того, ваше ядро должно поддерживать протокол IPv6.
Поэтому, лучше будет указать только одни IP адреса для psql
и в файле pg_hba.conf, вместо того чтобы полагаться на то, что /etc/hosts упорядочен должным образом. Это устраняет любые сомнения по поводу того какие IP-адреса разрешены или к какому серверу вы будете подключаться.
Запуск сервера
Поехали!
Теперь, запустите PostgreSQL и установите пароль для суперпользователя базы данных postgres.
Измените 'trust' на 'password' для соединений с 'host' (не с 'local' Unix сокетом).
root #
nano -w /etc/postgresql-9.3/pg_hba.conf
Теперь запустите базу данных:
root #
/etc/init.d/postgresql-9.3 start
postgresql-9.3 | * Starting PostgreSQL ... [ ok ]
Откройте соединение к серверу и установите пароль:
root #
psql -U postgres
psql (9.3.5) Type "help" for help.
postgres=#
\password
Enter new password: Enter it again:
postgres=#
\q
Измените 'trust' на 'password' для локальных соединений:
root #
nano -w /etc/postgresql-9.3/pg_hba.conf
Теперь перезагрузите настройки базы данных:
root #
/etc/init.d/postgresql-9.3 reload
postgresql-9.3 | * Reloading PostgreSQL configuration ... [ ok ]
Затем, когда все работает так, как нужно, включите загрузку PostgreSQL при старте системы:
root #
# rc-update add postgresql-9.3 default
* service postgresql-9.3 added to runlevel default
На данный момент вы готовы продолжать с официальным Руководством PostgreSQL. Это руководство проведет вас через создание ролей, баз данных, схем и все эти интересные и полезные вещи.
Миграция PostgreSQL
Когда вам требуется миграция
Существуют только две причины по которым вам необходимо выполнить миграцию: при переходе от одной главной версии к другой, например, от PostgreSQL 8.4.7 к 9.0.3, но не от 9.0.2 к 9.0.3; или при переключении с устаревшего формата временных меток с плавающей точкой к новому 64-битному целочисленному формату временных меток.
Вам потребуется выполнить миграцию базы данных при переходе со старых ebuild-файлов dev-db/libpq, dev-db/postgresql, dev-db/postgresql-libs и dev-db/postgresql-client, либо dev-db/postgresql версии старее, чем 9.0 к новому файлу ebuild dev-db/postgresql.
Миграция после версии 9.0
При обновлении с предыдущих версий файлов ebuild, а именно, версий после 8.4, прочитайте информацию, приведенную в начале данной статьи, перед тем, как осуществить миграцию.
С версией 9.0 и более поздними версиями поставляется новая утилита pg_upgrade, которая радикально упрощает процесс миграции.
Однако, имеются два предостережения при использовании утилиты pg_upgrade
. Во-первых, она не поддерживает файлы конфигурации, находящиеся не в каталоге с данными. Эту проблему можно решить использованием символьных ссылок. Во-вторых, её можно использовать только для миграции с базы данных версии 8.3 или новее. Если база данных старше, следуйте инструкциям по миграции с установок старше версии 9.0.
Остановите серверы с которых и на которые вы собираетесь мигрировать:
root #
/etc/init.d/postgresql-8.4 stop
root #
/etc/init.d/postgresql-9.3 stop
root #
ln -s /etc/postgresql-8.4/*.conf /var/lib/postgresql/8.4/data/
root #
ln -s /etc/postgresql-9.3/*.conf /var/lib/postgresql/9.3/data/
Символьные ссылки уже существуют начиная с версии 9.4 и более.
Проверьте доступные версии и затем выберите вашу:
root #
eselect postgresql list
root #
eselect postgresql set 9.3
Измените метод аутентификации пользователя базы данных 'postgres' так, чтобы доверять локальным соединениям на всех базах данных:
root #
nano -w /etc/postgresql-8.4/pg_hba.conf
root #
nano -w /etc/postgresql-9.3/pg_hba.conf
Может потребоваться изменить разрешения на /var/lib/postgresql/ перед выполнением следующего шага.
root #
su - postgres
user $
pg_upgrade -U postgres \
-d /var/lib/postgresql/8.4/data -D /var/lib/postgresql/9.3/data \
-b /usr/lib/postgresql-8.4/bin -B /usr/lib/postgresql-9.3/bin
PostgreSQL до версии 9.4 использовал опцию
-u
вместо -U
.На amd64 и других архитектурах, поддерживащих "multilib", исполняемые файлы находятся в /usr/lib64/postgresql-${PV}/bin.
Выполните команды, которые pg_upgrade
требует запустить, если таковые имеются.
user $
logout
И вот все готово:
root #
/etc/init.d/postgresql-9.3 start
Миграция перед версией 9.0: с помощью новых ebuild-файлов
По той причине, что новые ebuild-файлы предлагают более совершенный метод слоттинга, чем предыдущие, время простоя довольно мало, скорее всего это будут минуты, нежели часы.
В следующих примерах предполагается, что вы используете местоположения и настройки портов по умолчанию, и что вы мигрируете с 8.3 на 8.4. Отрегулируйте их соответствующим образом, если вы отклонились от значений по умолчанию.
Если вы еще этого не сделали, следуйте инструкциям по установке перед началом миграции. Такая компиляция может повлиять негативным образом на производительность сервера баз данных, но, тем не менее, она может выполняться.
Необходимо отредактировать пару файлов перед началом миграции. Установите PGPORT в файле конфигурации /etc/conf.d/postgresql-8.4 на 6543. (Подойдет любой порт отличный от того, который привязан к предыдущей установке.)
Затем, отредактируйте /etc/postgresql-8.3/pg_hba.conf так, чтобы только суперпользователь базы данных postgres мог получить доступ к кластеру базы данных через доменный сокет Unix.
root #
cp -p /etc/postgresql-8.3/pg_hba.conf /etc/postgresql-8.4/
Следующие инструкции должны быть безопасны. Прочтите документацию, чтобы быть в этом уверенными.
root #
cp -p /etc/postgresql-8.3/postgresql.conf /etc/postgresql-8.4/
Не забудьте скопировать те файлы конфигурации, которые могут вам понадобиться.
root #
/etc/init.d/postgresql-8.3 reload
root #
/etc/init.d/postgresql-8.4 start
Начинайте переправлять данные со старого кластера на новый кластер.
root #
pg_dumpall -U postgres -p 5432 | psql -U postgres -d postgres -p 6543
root #
/etc/init.d/postgresql-8.3 stop
root #
/etc/init.d/postgresql-8.4 stop
Установите PGPORT обратно на 5432.
root #
nano -w /etc/conf.d/postgresql-8.4
Разрешите пользователям доступ еще один раз.
root #
nano -w /etc/postgresql-8.4/pg_hba.conf
root #
/etc/init.d/postgresql-8.4 start
root #
rc-update del postgresql-8.3 && rc-update add postgresql-8.4 default
Надеемся, все прошло по плану и вы успешно обновили сервер, который содержит те же самые данные, точь-в-точь, как и старый сервер.
Миграция перед версией 9.0: со старых ebuild-файлов
Вам потребуется запланировать некоторое время простоя для вашего сервера. Старые ebuild-файлы не могут быть установлены в то же самое время, что и новые. Таким образом, заранее предположите, что сервер будет остановлен в течение нескольких часов. Даже, может быть, на все выходные.
Перед началом, вам понадобится запретить доступ к серверу, так, чтобы не сделать изменений. Вы также можете пожелать сделать резервное копирование postgresql.conf и pg_hba.conf и любого другого файла конфигурации, который вы считаете важным.
root #
pg_dumpall -U postgres > backup_file
root #
/etc/init.d/postgresql stop
root #
emerge -C dev-db/libpq dev-db/postgresql-client dev-db/postgresql-libs
Следуйте шагам по установке и конфигурации сервера, описанным в подробностях в этой статье.
root #
/etc/init.d/postgresql-8.4 start
root #
psql -f backup_file postgres
Вы можете повредить некоторые пакеты, которые были собраны с этими пакетами, но как только вы установили dev-db/postgresql, вы можете запустить revdep-rebuild
, чтобы заново установить любые пакеты, которые могут быть повреждены.
Утилиты
pgAdmin
pgAdmin — это графическая утилита для управления PostgreSQL. Она доступна в виде пакета dev-db/pgadmin4.
pgbouncer
PgBouncer is a connection pooling service. It is available as dev-db/pgbouncer.
Its main design goal is improving performance of short-lived connections.[1]
Устранение проблем
Устаревшие ebuild-файлы
Если у вас установлены какие-либо из следующих ebuild-файлов, то у вас очень старая и устаревшая инсталляция PostgreSQL, и вы должны мигрировать сейчас: dev-db/postgresql-libs, dev-db/postgresql-client, dev-db/libpq и dev-db/postgresql версии старее 9.0.
Раздельные файлы ebuild dev-db/postgresql-docs, dev-db/postgresql-docs, и/или dev-db/postgresql-server были объединены в единый пакет: dev-db/postgresql. Для того чтобы перейти от отдельных файлов ebuild к объединенному, вам не нужно ничего, кроме простой установки объединенного файла ebuild.
Эта статья описывает миграцию со старых ebuild-файлов к новым.
Сообщение "Server lacks instrumentation functions"
Эту проблему легко решить, с решением, зависящим от версии, которую вы используете. Что сложно, так это найти ответ. То, что потребуется — это импорт из файла, который уже существует на запоминающем устройстве: adminpack.sql. Чтобы решить эту проблему, запустите одну из следующих команд, соответствующую имеющейся версии:
Для PostgreSQL 9.0 и более ранних версий:
user $
psql -U postgres --file /usr/share/postgresql-9.0/contrib/adminpack.sql
Для PostgreSQL 9.1 и более поздних версий:
user $
psql -U postgres -c "CREATE EXTENSION adminpack;"
Отсутствующие файлы настроек в /etc/postgresql-9.x и /var/lib/postgresql/9.x/data
Вы можете попытаться переместить файлы настроек в каталог следующим образом (x - это ваша версия postgresql):
root #
cp /var/lib/postgresql/9.x/data/*.conf /etc/postgresql-9.x/
Если данные файлы отсутствуют, вам нужно их инициализировать.
Сначала зайдите как пользователь postgres:
root #
su postgres
Затем, как пользователь postgres, запустите initdb
и укажите каталог с данными:
user $
initdb -D /var/lib/postgresql/9.x/data/
После этого будут созданы файлы настроек, и вы сможете скопировать их в каталог /etc/postgresql-9.x/, как было показано в первом примере данного раздела.
Ошибки "ERROR: timezone directory stack overflow" или "FATAL: too many private dirs demanded"
Это вызвано ссылающимися друг на друга символическими ссылками. Чтобы исправить данную проблему, введите следующее:
root #
rm /usr/share/zoneinfo/posix
Помните, что любое обновление zoneinfo снова создаст данную символическую ссылку, и вам понадобится удалить ее снова.
systemd
Заставьте сервис запускаться при загрузке:
root #
systemctl enable postgresql-9.4
Чтобы запустить сервис немедленно:
root #
systemctl start postgresql-9.4
Если вы получите ошибку, проверьте, что существует каталог /run/postgresql/. Если он не существует, создайте его следующим образом:
root #
systemd-tmpfiles --create
Проверьте разрешения для файла настроек:
root #
ls -l /etc/postgresql-9.*/*
root #
chown postgres:postgres /etc/postgresql-9.*/*
root #
chmod 600 /etc/postgresql-9.*/*
Service file and changes to it
Systemd service files (postgresql-@SLOT@-.service) can be found in /lib/systemd/system/:
example config change:
[Service]
Environment=PGPORT=5433
This will override the setting appearing in /lib/systemd/system/postgresql-@SLOT@.service.
(source: postgresql-10.service file)
RemoveIPC
PostgreSQL recommends in wiki.postgresql.org/wiki/Systemd to change the RemoveIPC setting to no in /etc/systemd/logind.conf:
RemoveIPC=no
(source: wiki.postgresql.org/wiki/Systemd)
This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Aaron W. Swenson,Mikkel A. Clausen
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.
References
- ↑ PgBouncer command-line usage, pgbouncer. Retrieved on February 11, 2022