Не удается подключиться к postgresql через порт 5432

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

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

Сначала удалите старую установку postgres. В настоящее время проблема заключается в 9.1, поэтому я буду считать, что это то, что вы установили

sudo apt-get remove --purge postgresql-9.1

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

sudo apt-get install postgresql-9.1

Запишите название пакета с номером версии. НТН.

The error message refers to a Unix-domain socket, so you need to tweak your netstat invocation to not exclude them. So try it without the option -t:

netstat -nlp | grep 5432

I would guess that the server is actually listening on the socket /tmp/.s.PGSQL.5432 rather than the /var/run/postgresql/.s.PGSQL.5432 that your client is attempting to connect to. This is a typical problem when using hand-compiled or third-party PostgreSQL packages on Debian or Ubuntu, because the source default for the Unix-domain socket directory is /tmp but the Debian packaging changes it to /var/run/postgresql,

Возможные обходные пути:

• Use the clients supplied by your third-party package (call /opt/djangostack-1.3-0/postgresql/bin/psql). Возможно, удалите все пакеты, поставляемые с Ubuntu (это может быть сложно из-за других обратных зависимостей).
• Исправьте каталог сокетов стороннего пакета, чтобы он был совместим с Debian/Ubuntu.
• использование -H localhost to connect via TCP/IP instead.
• использование -h /tmp or equivalent PGHOST setting to point to the right directory.
• Не используйте сторонние пакеты.

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

Изменить: 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

Просто создайте мягкую ссылку, подобную этой:

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

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

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

netstat -lp --protocol=unix | grep postgres

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

Я заставляю это работать этим:

dpkg-reconfigure locales

Выберите предпочитаемые локали и запустите

pg_createcluster 9.5 main --start

(9.5 - это моя версия postgresql)

/etc/init.d/postgresql start

и тогда это работает!

sudo su - postgres
psql

Если ваша служба Postgres запущена и работает без каких-либо ошибок или при запуске службы Postgres нет ошибок, но вы все еще получаете указанную ошибку, выполните следующие действия.

Шаг 1: Бег pg_lsclusters выведет список всех кластеров postgres, работающих на вашем устройстве

например:

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

Скорее всего, статус будет ниже в вашем случае и сервис Postgres

Шаг 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

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

Если нет, запустите

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

Шаг 5: Проверьте, что пользователь postgres принадлежит к группе пользователей ssl-cert

Оказалось, что я ошибочно удалил пользователя Postgres из 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 8.1 на Debian Squeeze, потому что я использую Project Open, который основан на OpenACS и не будет работать на более поздних версиях PostgreSQL.

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

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

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

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,

Я обнаружил, что удаление Postgres звучит неубедительно. Это помогает решить мою проблему:

1. Запустите сервер postgres:

   sudo systemctl start postgresql
   

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

   sudo systemctl enable postgresql
   

Подробную информацию можно найти на сайте DigitalOcean здесь.

Решение:

Сделай это

export LC_ALL="en_US.UTF-8"

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

sudo pg_createcluster 9.3 main --start

Я не смог решить эту проблему с моим сервером postgres-9.5. После 3 дней нулевого прогресса, пробуя каждую перестановку исправлений на этом и других сайтах, я решил переустановить сервер и потерять 5 дней работы. Но я повторил проблему на новом экземпляре. Это может дать некоторое представление о том, как это исправить, прежде чем использовать катастрофический подход, который я сделал.

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

# ERROR REPORTING AND LOGGING

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

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

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

Если это не помогает, то подумайте:

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

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

В моем случае это было вызвано опечаткой, которую я сделал при редактировании /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

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

Попробуйте изменить его на 700, используя команду ниже:

sudo chmod 700 main

Ответ , получивший наибольшее количество голосов , даже отдаленно неверен, потому что вы можете видеть в вопросе, что сервер работает на ожидаемом порту (он показывает это с помощью netstat).

Хотя ОП не отметил другой ответ как выбранный, они отметили, что другого ответа (который имеет смысл и работает) было достаточно ,

Но по этим причинам это решение плохое и небезопасное , даже если сервер не работает на порту 5432:

Что ты здесь делаешь, когда говоришь --purgeвы удаляете файл конфигурации для PostgreSQL ((а также все данные с базой данных. Возможно, вы даже не видите предупреждение об этом, но это предупреждение просто для того, чтобы показать вам сейчас,

Удаление пакета сервера PostgreSQL оставит существующие кластеры баз данных нетронутыми, т. е. их каталоги конфигурации, данных и журналов не будут удалены. При очистке пакета каталоги могут быть удалены. Удалить каталоги PostgreSQL при очистке пакета? [подскажите да или нет]

Когда вы добавляете его снова, PostgreSQL переустанавливает его на номер порта, который не занят (который может быть тем номером порта, который вы ожидаете). Прежде чем вы даже попробуете это решение , вам нужно ответить на несколько вопросов в том же духе:

• Нужно ли мне несколько версий PostgreSQL на моей машине?
• Нужна ли мне более старая версия PostgreSQL?
• Что я хочу, чтобы произошло, когда я и есть более новая версия?

В настоящее время, когда вы используете Ubuntu (и любой вариант Debian), новая версия PostgreSQL устанавливается вместе со старой копией, а номер порта в новой копии равен номеру порта старой копии + 1. Таким образом, вы можете просто запустить его, увеличьте номер порта в вашем клиенте, и вы получите новую установку! И у вас есть старая установка, на которую можно вернуться — это безопасно!

Однако, если вам нужна только одна версия очистки PostgreSQL для изменения конфигурации, это все равно не лучший вариант, поскольку он уничтожит вашу базу данных . Единственный случай, когда это может быть допустимо, — это когда вы хотите уничтожить все , что связано с PostgreSQL. Вам лучше убедиться, что ваша база данных верна, а затем просто отредактировать файл конфигурации, чтобы новая установка выполнялась на старом номере порта.

      #!/bin/bash

# We can find the version number of the newest PostgreSQL with this
VERSION=$(dpkg-query -W -f "\${Version}" 'postgresql' | sed -e's/+.*//')
PGCONF="/etc/postgresql/${VERSION}/main/postgresql.conf"

# Then we can update the port.
sudo sed -ie '/port = /s/.*/port = 5432/' "$PGCONF"

sudo systemctl restart postgresql

Не устанавливайте определенную версию PostgreSQL. Всегда устанавливайте только postgresql. Если вы устанавливаете конкретную версию, то при dist-upgradeваша версия просто останется на вашем компьютере навсегда без обновлений. В репозитории больше не будет исправлений безопасности для старой версии (которую они не поддерживают). Это всегда должно быть неоптимально для получения более новой версии, которую они поддерживают, работающей на другом номере порта.

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

Моя установка: подсистема Windows для Linux, Docker-compose с make-файлом с dockerfile, Flask, Postgresql (с использованием схемы, состоящей из таблиц)

Чтобы подключиться к postgres, настройте строку подключения следующим образом:

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>")

У меня была такая же проблема (на 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

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

Эта ошибка может означать много разных вещей.

В моем случае я бежал PostgreSQL 12на виртуальной машине.

Я изменил конфигурацию, и, по-видимому, системный администратор отредактировал конфигурацию памяти для виртуальной машины, уменьшив выделение ОЗУ с того места, где оно было, до уровня ниже того, что я установил для виртуальной машины. shared_buffer.

Я понял это, посмотрев логин

      /var/log/postgresql/postgresql-12-main.log

и после этого я перезапустил службу, используя

      sudo systemctl restart postgresql.service

вот как это сработало

После многих изнурительных попыток я нашел решение, основанное на других постах!

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

Имея ту же проблему, я попробовал что-то другое:

Запустив демон 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.

Перезапустите postgresql с помощью команды

      sudo /opt/bitnami/ctlscript.sh restart postgresql

1. Проверьте статус:

           service postgresql status
   

   Если он отображается онлайн, перейдите к шагу № 3, в противном случае выполните шаг № 2.

2. Делать postgresqlонлайн, выполните следующую команду:

           sudo service postgresql start
   

   Теперь проверьте статус, выполнив команду предыдущего шага. Он должен показывать онлайн.

3. Начать psqlсессии выполните следующую команду:

           sudo su postreg
   

4. Наконец, проверьте, работает ли он или нет, выполнив:

           psql
   

В моем случае у меня были установлены предыдущие версии, и это вызвало беспорядок. Я очистил эти файлы, удалил все и переустановил Postgres. Это решено.

У меня была та же самая проблема, которую описал Питер Эйзентро. С использованием 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 тоже правильно настроен.

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

sudo service postgresql restart

а потом

sudo -u postgres psql

Это работало просто отлично. Надеюсь, поможет. Ура:) .

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

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

Результат:

/tmp/.s.PGSQL.5432

Войти как пользователь postgres:

su postgres
psql -h /tmp/ yourdatabase

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

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

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

postgresql.conf

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

У меня была эта проблема с другим портом. Проблема была в том, что у меня была системная переменная в /etc/environmentsсо следующим значением:

PGPORT=54420

Когда я удалил его (и перезапустил), psql смог подключиться.