Не может соединиться с postgresql на порте 5432

Можно использовать psql -U postgres -h localhost вынудить соединение произойти по TCP вместо сокетов домена UNIX; Ваш netstat вывод показывает, что сервер PostgreSQL слушает на порте localhost 5432.

Можно узнать, какой локальный сокет UNIX используется сервером PostgrSQL при помощи другого invocavtion netstat:

netstat -lp --protocol=unix | grep postgres

Во всяком случае интерфейсы, в которых сервер PostgreSQL слушает, настроены в postgresql.conf.

Сообщение об ошибке относится к доменному Unix сокету, таким образом, необходимо настроить Ваш netstat вызов для не исключения их. Так попробуйте его без опции -t:

netstat -nlp | grep 5432

Я предположил бы, что сервер на самом деле слушает на сокете /tmp/.s.PGSQL.5432 вместо /var/run/postgresql/.s.PGSQL.5432 то, что Ваш клиент пытается соединиться с. Это - типичная проблема при использовании скомпилированных в руку или сторонних пакетов PostgreSQL на Debian или Ubuntu, потому что исходное значение по умолчанию для доменного Unix каталога сокета /tmp но Debian, упаковывающий, изменяет его на /var/run/postgresql.

Возможные обходные решения:

• Используйте клиенты, предоставленные Вашим сторонним пакетом (вызов /opt/djangostack-1.3-0/postgresql/bin/psql). Возможно удалите предоставленные Ubuntu пакеты в целом (могло бы быть трудным из-за других обратных зависимостей).
• Исправьте каталог сокета стороннего пакета, чтобы быть совместимыми с Debian/Ubuntu.
• Использовать -H localhost соединяться через TCP/IP вместо этого.
• Использовать -h /tmp или эквивалентный PGHOST установка для указания на правильный каталог.
• Не используйте сторонние пакеты.

Я должен был скомпилировать PostgreSQL 8.1 на Debian, Сжимают, потому что я использую Открытый Проект, который основан на OpenACS и не будет работать на более поздних версиях PostgreSQL.

Конфигурация компиляции по умолчанию помещает unix_socket в /tmp, но Открытый Проект, который полагается на PostgreSQL, не работал бы, потому что он ищет unix_socket в /var/run/postgresql.

Существует установка в postgresql.conf установить местоположение сокета. Моя проблема состояла в том, что любой я мог установить для /tmp и psql обработанный, но не открытый проект, или я мог установить его для /var/run/postgresql и psql не работал бы, но открытый проект сделал.

Одно разрешение к проблеме состоит в том, чтобы установить сокет для /var/run/postgresql и затем выполненный psql, на основе предложения Peter, как:

psql -h /var/run/postgresql

Это выполняет локально использующие локальные полномочия. Единственный недостаток состоит в том, что это больше вводит, чем просто "psql".

Другое предположение, что кто-то сделал, состояло в том, чтобы создать символьную ссылку между этими двумя местами. Это также работало, но, ссылка исчезла на перезагрузку. Это, возможно, легче просто использовать-h аргумент, однако, я создал символьную ссылку из сценария PostgreSQL в /etc/init.d. Я поместил, символьная ссылка создают команду в разделе "запуска". Конечно, когда я выпускаю остановку и запускаю или перезапускаю команду, она попытается воссоздать существующую символьную ссылку, но кроме предупреждающего сообщения, нет, вероятно, никакого вреда в этом.

В моем случае, вместо:

ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432

Я имею

ln -s /var/run/postgresql/.s.PGSQL.5432 /tmp/.s.PGSQL.5432

и явно установили unix_socket на /var/run/postgresql/.s.PGSQL.5432 в postgresql.conf.

Просто создайте softlink как это:

ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432

Эта проблема прибывает из установки postgres пакет без номера версии. Хотя postgres будет установлен и это будет правильная версия, сценарий для установки кластера не будет работать правильно; это - упаковочная проблема.

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

Сначала произведите чистку старой установки пост-ГРЭС. Проблема в настоящее время находится с 9,1, таким образом, я предположу, что это - то, что Вы установили

sudo apt-get remove --purge postgresql-9.1

Теперь просто переустановите

sudo apt-get install postgresql-9.1

Отметьте имя пакета с номером версии. HTH.

При наличии той же проблемы я попробовал что-то другое:

При запуске postgresql демона вручную я добрался:

FATAL:  could not create shared memory segment ...
   To reduce the request size (currently 57237504 bytes), reduce PostgreSQL's
   shared memory usage, perhaps by reducing shared_buffers or max_connections.

Таким образом, то, что я сделал, должно было установить нижний предел для shared_buffers и max_connections в postgresql.conf и restart сервис.

Это решило проблему!

Вот полный журнал ошибок:

$ sudo service postgresql start
 * Starting PostgreSQL 9.1 database server                                                                                                                                                               * The PostgreSQL server failed to start. Please check the log output:
2013-06-26 15:05:11 CEST FATAL:  could not create shared memory segment: Invalid argument
2013-06-26 15:05:11 CEST DETAIL:  Failed system call was shmget(key=5432001, size=57237504, 03600).
2013-06-26 15:05:11 CEST HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.  You can either reduce the request size or reconfigure the kernel with larger SHMMAX.  To reduce the request size (currently 57237504 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
    If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter, in which case raising the request size or reconfiguring SHMMIN is called for.
    The PostgreSQL documentation contains more information about shared memory configuration.

Возможно это, возможно, произошло, потому что Вы изменили полномочия /var/lib/postgresql/9.3/main папка.

Попытайтесь изменить его на 700 использований команды ниже:

sudo chmod 700 main

Это работает на меня:

Править: postgresql.conf

sudo nano /etc/postgresql/9.3/main/postgresql.conf

Включите или добавьте:

listen_addresses = '*'

Перезапустите механизм базы данных:

sudo service postgresql restart

Кроме того, можно проверить файл pg_hba.conf

sudo nano /etc/postgresql/9.3/main/pg_hba.conf

И добавьте свой сетевой адрес или адрес узла:

host    all             all             192.168.1.0/24          md5

У меня была та же проблема (на (коварной) Ubuntu 15.10). sudo find / -name 'pg_hba.conf' -print или sudo find / -name 'postgresql.conf' -print поднятый пустой. Перед этим казалось, что были установлены несколько экземпляров postgresql.

Вы могли бы иметь подобный, когда Вы видите, как установлено, или список проблем зависимости

.../postgresql
.../postgresql-9.x 

и так далее.

В этом случае Вы должны sudo apt-get autoremove каждый пакет 1 на 1.

Затем после этого к букве и Вы будете в порядке. Особенно когда дело доходит до ключевого импорта и добавления к источнику перечисляют СНАЧАЛА

sudo apt-get update && sudo apt-get -y install python-software-properties && wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

Не используя коварный, замена wily с Вашим выпуском, т.е. с выводом lsb_release -cs

sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ wily-pgdg main" >> /etc/apt/sources.list.d/postgresql.list'
sudo apt-get update && sudo apt-get install postgresql-9.3 pgadmin3

И затем необходимо быть в порядке и смочь соединить и создать пользователей.

Ожидаемый вывод:

Creating new cluster 9.3/main ...
config /etc/postgresql/9.3/main
data   /var/lib/postgresql/9.3/main
locale en_US.UTF-8
socket /var/run/postgresql
port   5432

Источник моих решений (кредиты)

У меня была та же самая проблема, которую описал Peter Eisentraut. Используя netstat -nlp | grep 5432 команда, я видел, что сервер слушал на сокете /tmp/.s.PGSQL.5432.

Для фиксации этого просто отредактируйте Ваш postgresql.conf файл и изменение следующие строки:

listen_addresses = '*'
unix_socket_directories = '/var/run/postgresql'

Теперь выполненный service postgresql-9.4 restart (Замените 9-4 своей версией), и удаленные соединения должны работать теперь.

Теперь для разрешения локальных соединений просто создайте символьную ссылку на /var/run/postgresql каталог.

ln -s /var/run/postgresql/.s.PGSQL.5432 /tmp/.s.PGSQL.5432

Не забывайте удостоверяться Ваш pg_hba.conf правильно настроен также.

Решение:

Сделайте это

export LC_ALL="en_US.UTF-8"

и это. (9.3 моя текущая версия PostgreSQL. Запишите свою версию!)

sudo pg_createcluster 9.3 main --start

Найдите свой файл:

sudo find /tmp/ -name .s.PGSQL.5432

Результат:

/tmp/.s.PGSQL.5432

Вход в систему как пользователь пост-ГРЭС:

su postgres
psql -h /tmp/ yourdatabase

В моем случае все, что я должен был сделать, было этим:

sudo service postgresql restart

и затем

sudo -u postgres psql

Это работало просто великолепно. Надежда это помогает. Аплодисменты :).

В моем случае это было вызвано опечаткой, которую я сделал при редактировании /etc/postgresql/9.5/main/pg_hba.conf

Я изменился:

# Database administrative login by Unix domain socket
local   all             postgres                                peer

кому:

# Database administrative login by Unix domain socket
local   all             postgres                                MD5

Но MD5 должен был быть нижний регистр md5:

# Database administrative login by Unix domain socket
local   all             postgres                                md5

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

Во-первых, отключите все настройки входа в postgresql.conf. Это - раздел:

# ERROR REPORTING AND LOGGING

Прокомментируйте все в том разделе. Затем перезапустите сервис.

При перезапуске использовать /etc/init.d/postgresql start или restart Я нашел полезным быть в режиме суперпользователя при перезапуске. У меня было X-окно, открытое только для той операции. Можно установить тот режим суперпользователя с sudo -i.

Проверьте, что сервер может быть достигнут с этой простой командой: psql -l -U postgres

Если это не фиксирует его, то рассмотрите это:

Я изменял владение на многих папках при попытке найти решение. Я знал, что буду, вероятно, пытаться вернуться те владения папки и chmods в течение еще 2 дней. Если Вы уже смешали с теми владениями папки и не хотите полностью производить чистку своего сервера, то начните отслеживать настройки для всех затронутых папок для возвращения их исходному состоянию. Вы могли бы хотеть попытаться сделать параллельную установку в другой системе и систематически проверять владение и настройки всех папок. Утомительный, но Вы можете получать доступ к своим данным.

После того как Вы действительно получаете доступ, систематически изменяете каждую соответствующую строку в # ERROR REPORTING AND LOGGING раздел postgresql.conf файл. Перезапуск и тест. Я нашел, что папка по умолчанию для журналов вызывала отказ. Я конкретно прокомментировал log_directory. Папка по умолчанию, в которую система отбрасывает журналы, затем /var/log/postgresql.

Я заставляю его работать путем выполнения этого:

dpkg-reconfigure locales

Выберите свои предпочтительные локали, затем выполненные

pg_createcluster 9.5 main --start

(9.5 моя версия postgresql),

/etc/init.d/postgresql start

и затем это работает!

sudo su - postgres
psql

Я нашел, что Пост-ГРЭС удаления звучит неубедительной. Это помогает решить мою проблему:

1. Запустите сервер пост-ГРЭС:

   sudo systemctl start postgresql
   

2. Удостоверьтесь, что сервер запускается на начальной загрузке:

   sudo systemctl enable postgresql
   

Подробная информация может быть найдена на сайте DigitalOcean Здесь.

Если Ваши услуги Пост-ГРЭС в порядке без какой-либо ошибки или нет никакой ошибки в запуске услуг Пост-ГРЭС, и тем не менее Вы получаете упомянутую ошибку, выполняете эти шаги

Step1: выполнение pg_lsclusters перечислит все кластеры пост-ГРЭС, работающие на Вашем устройстве

например:

Ver Cluster Port Status Owner    Data directory               Log file
9.6 main    5432 online postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log

по всей вероятности состояние снизится в Вашем случае и услугах пост-ГРЭС

Шаг 2: Перезапустите pg_ctlcluster

#format is pg_ctlcluster <version> <cluster> <action>
sudo pg_ctlcluster 9.6 main start

#restart postgres
sudo service postgres restart

Шаг 3: Шаг 2 привел к сбою и бросил ошибку

Если этот процесс не будет успешен, то он бросит ошибку. Вы видите журнал ошибок на /var/log/postgresql/postgresql-9.6-main.log

Моя ошибка была:

FATAL: could not access private key file "/etc/ssl/private/ssl-cert-snakeoil.key": Permission denied
Try adding `postgres` user to the group `ssl-cert`

Шаг 4: проверьте владение пост-ГРЭС

Удостоверьтесь это postgres владелец /var/lib/postgresql/version_no/main

В противном случае выполненный

sudo chown postgres -R /var/lib/postgresql/9.6/main/

Шаг 5: Проверьте, что пользователь пост-ГРЭС принадлежит группе пользователей ssl-сертификата

Оказалось, что я ошибочно удалил пользователя Пост-ГРЭС из ssl-cert группа. Работайте ниже кода, чтобы устранить проблему группы пользователей и исправить полномочия

#set user to group back with
sudo gpasswd -a postgres ssl-cert

# Fix ownership and mode
sudo chown root:ssl-cert  /etc/ssl/private/ssl-cert-snakeoil.key
sudo chmod 740 /etc/ssl/private/ssl-cert-snakeoil.key

# now postgresql starts! (and install command doesn't fail anymore)
sudo service postgres restart

Создайте postgresql каталог в выполненном и затем выполните следующую команду.

ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/.s.PGSQL.5432

После многих исчерпывающих попыток я нашел решение на основе других сообщений!

dpkg -l | grep postgres
apt-get --purge remove <package-founded-1> <package-founded-2>
whereis postgres
whereis postgresql
sudo rm -rf <paths-founded>
sudo userdel -f postgres

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

Моя установка: Windows Subsystem для Linux, Докер - составляет w/make-файл w/dockerfile, Флягу, Postgresql (использующий схему, состоящую из таблиц)

Для соединения с пост-ГРЭС установите строку подключения как это:

from flask import Flask
app = Flask(__name__)
app.config['SQLALCHEMY_DATABASE_URI'] = "postgresql+psycopg2://<user>:<password>@<container_name_in_docker-compose.yml>/<database_name>"

Примечание: Я никогда не заставлял IP (например, localhost, 127.0.0.1) работать с помощью любого метода в этом потоке. Идея для использования контейнерного имени вместо localhost прибыла отсюда: https://github.com/docker-library/postgres/issues/297

Установите свою схему:

from sqlalchemy import MetaData
db = SQLAlchemy(app, metadata=MetaData(schema="<schema_name>"))

Установите свой путь поиска для Ваших функций при установке сессии:

db.session.execute("SET search_path TO <schema_name>")

Просто добавьте/tmp unix_socket_directories

postgresql.conf

unix_socket_directories = '/var/run/postgresql,/tmp'