Psql ошибка подключиться к серверу через сокет

This issue comes from installing the postgres package without a version number. Although postgres will be installed and it will be the correct version, the script to setup the cluster will not run correctly; it’s a packaging issue.

If you’re comfortable with postgres there is a script you can run to create this cluster and get postgres running. However, there’s an easier way.

First purge the old postgres install, which will remove everything of the old installation, including databases, so back up your databases first.. The issue currently lies with 9.1 so I will assume that’s what you have installed

sudo apt-get remove --purge postgresql-9.1

Now simply reinstall

sudo apt-get install postgresql-9.1

Note the package name with the version number. HTH.

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.

Possible workarounds:

• Use the clients supplied by your third-party package (call /opt/djangostack-1.3-0/postgresql/bin/psql). Possibly uninstall the Ubuntu-supplied packages altogether (might be difficult because of other reverse dependencies).
• Fix the socket directory of the third-party package to be compatible with Debian/Ubuntu.
• Use -H localhost to connect via TCP/IP instead.
• Use -h /tmp or equivalent PGHOST setting to point to the right directory.
• Don’t use third-party packages.

This works for me:

Edit: postgresql.conf

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

Enable or add:

listen_addresses = '*'

Restart the database engine:

sudo service postgresql restart

Also, you can check the file pg_hba.conf

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

And add your network or host address:

host    all             all             192.168.1.0/24          md5

You can use psql -U postgres -h localhost to force the connection to happen over TCP instead of UNIX domain sockets; your netstat output shows that the PostgreSQL server is listening on localhost’s port 5432.

You can find out which local UNIX socket is used by the PostgrSQL server by using a different invocavtion of netstat:

netstat -lp --protocol=unix | grep postgres

At any rate, the interfaces on which the PostgreSQL server listens to are configured in postgresql.conf.

answered Jun 26, 2011 at 12:51

Just create a softlink like this :

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

answered Jul 9, 2012 at 1:35

I make it work by doing this:

dpkg-reconfigure locales

Choose your preferred locales then run

pg_createcluster 9.5 main --start

(9.5 is my version of postgresql)

/etc/init.d/postgresql start

and then it works!

sudo su - postgres
psql

I had to compile PostgreSQL 8.1 on Debian Squeeze because I am using Project Open, which is based on OpenACS and will not run on more recent versions of PostgreSQL.

The default compile configuration puts the unix_socket in /tmp, but Project Open, which relies on PostgreSQL, would not work because it looks for the unix_socket at /var/run/postgresql.

There is a setting in postgresql.conf to set the location of the socket. My problem was that either I could set for /tmp and psql worked, but not project open, or I could set it for /var/run/postgresql and psql would not work but project open did.

One resolution to the issue is to set the socket for /var/run/postgresql and then run psql, based on Peter’s suggestion, as:

psql -h /var/run/postgresql

This runs locally using local permissions. The only drawback is that it is more typing than simply «psql».

The other suggestion that someone made was to create a symbolic link between the two locations. This also worked, but, the link disappeared upon reboot. It maybe easier to just use the -h argument, however, I created the symbolic link from within the PostgreSQL script in /etc/init.d. I placed the symbolic link create command in the «start» section. Of course, when I issue a stop and start or restart command, it will try to recreate an existing symbolic link, but other than warning message, there is probably no harm in that.

In my case, instead of:

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

I have

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

and have explicitly set the unix_socket to /var/run/postgresql/.s.PGSQL.5432 in postgresql.conf.

If your Postgres service is up and running without any error or there is no error in starting the Postgres service and still you are getting the mentioned error, follow these steps

Step1: Running pg_lsclusters will list all the postgres clusters running on your device

eg:

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

most probably the status will be down in your case and postgres service

Step 2: Restart the pg_ctlcluster

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

#restart postgresql service
sudo service postgresql restart

Step 3: Step 2 failed and threw error

If this process is not successful it will throw an error. You can see the error log on /var/log/postgresql/postgresql-9.6-main.log

My error was:

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`

Step 4: check ownership of postgres

Make sure that postgres is the owner of /var/lib/postgresql/version_no/main

If not, run

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

Step 5: Check postgres user belongs to ssl-cert user group

It turned out that I had erroneously removed the Postgres user from the ssl-cert group. Run the below code to fix the user group issue and fix the permissions

#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 postgresql restart

answered Feb 1, 2018 at 15:45

Solution:

Do this

export LC_ALL="en_US.UTF-8"

and this. (9.3 is my current PostgreSQL version. Write your version!)

sudo pg_createcluster 9.3 main --start

answered Feb 23, 2016 at 21:47

In my case it was caused by a typo I made while editing /etc/postgresql/9.5/main/pg_hba.conf

I changed:

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

to:

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

But MD5 had to be lowercase md5:

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

answered Nov 29, 2016 at 10:15

answered Jan 19, 2017 at 1:34

answered Nov 6, 2014 at 13:01

Evan CarrollEvan Carroll

7,30615 gold badges53 silver badges87 bronze badges

answered Jan 30, 2017 at 15:18

answered Feb 5, 2016 at 16:43

answered Jun 26, 2013 at 13:29

After many exhausting attempts, I found the solution based on other posts!

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

answered May 29, 2021 at 12:21

Create postgresql directory inside run and then run the following command.

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

answered Apr 26, 2019 at 5:35

Simply add /tmp unix_socket_directories

postgresql.conf

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

answered Jun 17, 2019 at 1:00

I had this problem with another port. The problem was, that I had a system variable in /etc/environments with the following value:

PGPORT=54420

As I removed it (and restarted), psql was able to connect.

answered Jul 18, 2021 at 14:46

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

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

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

sudo apt-get remove --purge postgresql-9.1

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

sudo apt-get install postgresql-9.1

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

Stewart

19 авг ’13 в 23:54
2013-08-19 23:54

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

angelous

09 окт ’14 в 13:17
2014-10-09 13:17

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

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

netstat -lp --protocol=unix | grep postgres

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

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

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

Uriel

09 июл ’12 в 01:35
2012-07-09 01:35

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

dpkg-reconfigure locales

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

pg_createcluster 9.5 main --start

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

/etc/init.d/postgresql start

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

sudo su - postgres
psql

mymusise

13 сен ’16 в 09:05
2016-09-13 09:05

Если ваша служба 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

Noushad

16 апр ’18 в 14:44
2018-04-16 14:44

Мне пришлось скомпилировать 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,

Joe

06 ноя ’12 в 03:22
2012-11-06 03:22

Я обнаружил, что удаление 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

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

Я не смог решить эту проблему с моим сервером 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,

Ответ , получивший наибольшее количество голосов , даже отдаленно неверен, потому что вы можете видеть в вопросе, что сервер работает на ожидаемом порту (он показывает это с помощью 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ваша версия просто останется на вашем компьютере навсегда без обновлений. В репозитории больше не будет исправлений безопасности для старой версии (которую они не поддерживают). Это всегда должно быть неоптимально для получения более новой версии, которую они поддерживают, работающей на другом номере порта.

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

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

sudo chmod 700 main

Farzin

06 ноя ’14 в 13:01
2014-11-06 13:01

Это не совсем связано с вопросом, так как я использую 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>")

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

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

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

Grmn

05 фев ’16 в 16:43
2016-02-05 16:43

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

В моем случае я бежал
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.

DrFalk3n

26 июн ’13 в 13:29
2013-06-26 13:29

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

      sudo /opt/bitnami/ctlscript.sh restart postgresql

Jasir

26 апр ’22 в 09:41
2022-04-26 09:41

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

           service postgresql status
   

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

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

           sudo service postgresql start
   

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

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

           sudo su postreg
   

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

           psql
   

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

sudo service postgresql restart

а потом

sudo -u postgres psql

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

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

18 окт ’20 в 19:56
2020-10-18 19:56

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

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

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

PGPORT=54420

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

Bevor

18 июл ’21 в 14:46
2021-07-18 14:46

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

postgresql.conf

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

Blue

17 июн ’19 в 04:00
2019-06-17 04:00