Ответ 1
Я решил эту проблему, удалив и переустановив ее
После моего обновления к горному льву мои постгресы выполняют работу. Он по-прежнему работает, но мои приложения не могут подключиться к нему больше.
$ ps aux | grep postgres
postgres 204 0.0 0.0 2446960 836 ?? Ss 7:31AM 0:00.59 postgres: stats collector process
postgres 203 0.0 0.1 2478732 2240 ?? Ss 7:31AM 0:00.41 postgres: autovacuum launcher process
postgres 202 0.0 0.0 2478600 584 ?? Ss 7:31AM 0:00.34 postgres: wal writer process
postgres 201 0.0 0.0 2478600 784 ?? Ss 7:31AM 0:00.48 postgres: writer process
postgres 95 0.0 0.0 2446960 368 ?? Ss 7:31AM 0:00.11 postgres: logger process
postgres 64 0.0 0.2 2478600 7972 ?? Ss 7:31AM 0:00.26 /Library/PostgreSQL/9.1/bin/postmaster -D/Library/PostgreSQL/9.1/data
anezio 10205 0.0 0.0 2432768 624 s000 R+ 8:01AM 0:00.00 grep postgres
и мои приложения возвращают эту ошибку:
could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/pgsql_socket/.s.PGSQL.5432"?
Я все еще могу подключиться к psql с помощью команды /Library/PostgreSQL/ 9.1/bin/psql -U postgres
Кажется, что что-то не указывает на нужное место
Я решил эту проблему, удалив и переустановив ее
У меня была такая же проблема. Лично я просто переустановил из установщика Postgres (postgresql-9.1.3-1-osx.dmg в моем случае), перезагрузил мой Mac, и все в порядке. постскриптум переустановка не удалила мои базы данных:)
Проверьте, какой psql
вы используете. У меня была та же проблема при использовании сервера Postgres.app из Heroku и выяснилось, что я использовал клиент Apple /usr/bin/psql
на основе моего параметра $PATH
. Либо установите $PATH
в свою библиотеку Postgres, либо используйте полный путь к установленному psql
.
Путь сокетов домена Unix по умолчанию жестко запрограммирован в libpq. Что может произойти, так это то, что до обновления ваше приложение использовало библиотеку libpq, установленную установщиком One-click Postgres, а после обновления была выбрана другая версия этой библиотеки.
Чтобы обойти проблему, с точки зрения программиста, вы можете указать каталог сокета вместо того, чтобы полагаться на значение по умолчанию. Чтобы найти правильный каталог, если вы его еще не знаете, подключитесь к любой базе данных в качестве суперпользователя (обычно postgres) и выполните SQL:
SHOW unix_socket_directory;
Затем измените или перенастройте приложение с помощью пути, полученного в поле хоста вызова соединения (например, в строке подключения: host=/path/to/socket dbname=d user=u
). Libpq распознает его как каталог сокетов unix, потому что он начинается с косой черты, в отличие от имени хоста или IP-адреса.
Как-то я полностью забыл, что этот файл сокета будет скрыт из-за точки. Убедитесь, что вы используете ls -A /tmp/.s.PGSQL.5432
, если вы проверяете, действительно ли есть сокет.
Приложение postgres начало принимать соединение из psql после того, как я сделал следующее. Я думаю, что это имело какое-то отношение к шагу 3.
postgres -D ~/Library/Application\ Support/Postgres/var
. Это каталог данных, если вы используете приложение postgres. Если вы не используете приложение postgres, вам нужно выяснить, что такое каталог данных.psql
. Вы должны подключиться успешно.\q
для выхода из psql.ctrl c
, чтобы остановить postgres.Проблема заключается в том, что у горного льва есть собственный клиент psql (/usr/bin/psql), который, по-видимому, пытается подключить postgres путем поиска локального файла сокета в другом месте, чем тот, который установлен в вашем установщике. Вы можете либо изменить свою переменную PATH, чтобы сначала включить вашу папку postgres bin, либо заменить значение по умолчанию /usr/bin/psql тем, что было в вашей установке.