it-swarm.com.de

PostgreSQL wird lokal ausgeführt, aber ich kann keine Verbindung herstellen. Warum?

Kürzlich wurde mein Computer von Mac OS X Lion (10.7.4) auf Mountain Lion (10.8) aktualisiert, und ich denke, es hat meine PostgreSQL-Installation gestört. Es wurde ursprünglich über Homebrew installiert. Ich bin kein DBA, hoffe aber, dass mir jemand sagen kann, wie ich das beheben kann.

Ich kann keine Verbindung herstellen (konnte aber vor dem Mountain Mountain):

$ psql -U Rails -d myapp_development
psql: 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"?

Aber Postgres läuft immer noch klar:

$ ps aux | grep postgres
meltemi          2010   0.0  0.0  2444124   5292   ??  Ss   Wed01PM   0:00.02 postgres: Rails myapp_development [local] idle    
meltemi           562   0.0  0.0  2439312    592   ??  Ss   Wed12PM   0:02.28 postgres: stats collector process       
meltemi           561   0.0  0.0  2443228   1832   ??  Ss   Wed12PM   0:01.57 postgres: autovacuum launcher process       
meltemi           560   0.0  0.0  2443096    596   ??  Ss   Wed12PM   0:02.89 postgres: wal writer process       
meltemi           559   0.0  0.0  2443096   1072   ??  Ss   Wed12PM   0:04.01 postgres: writer process       
meltemi           466   0.0  0.0  2443096   3728   ??  S    Wed12PM   0:00.85 /usr/local/bin/postgres -D /usr/local/varpostgres -r /usr/local/var/postgres/server.log

Und es antwortet auf Anfragen (sowohl an eine Test-Datenbank als auch an die Entwicklungs-Datenbank) von einer lokalen Rails App)

  User Load (0.2ms)  SELECT "users".* FROM "users" 
  Rendered users/index.html.haml within layouts/application (1.3ms)

Es scheint kein /var/pgsql_socket/ Verzeichnis, geschweige denn das /var/pgsql_socket/.s.PGSQL.5432 oben erwähnte Socket-Datei!?! Vielleicht hat die Installation von Mountain Lion das ausgelöscht?

$ ls -l /var/ | grep pg
drwxr-x---   2 _postgres  _postgres    68 Jun 20 16:39 pgsql_socket_alt

Wie kann ich das beheben?

32
Meltemi

Ich stellte fest, dass ich ein äußerst ähnliches Problem hatte, nämlich dass Postgres einen Socket in /var/pgsql_socket_alt Öffnete, in dem keine meiner Software erwartet, aber die Lösung für mein Problem war nicht nur ein Problem mit meinem $PATH.

Ich musste das Verzeichnis /var/pgsql_socket Erstellen, es mir selbst zeigen und unix_socket_directory In postgresql.conf (In /usr/local/var/postgres) In dieses Verzeichnis setzen und dann das verwenden pg_ctl Binär in /usr/local/bin, Um den richtigen Postgres-Server erfolgreich zu starten (hier kommt $PATH Ein - stellen Sie sicher, dass which pg_ctl In /usr/local/bin/pg_ctl Aufgelöst wird. oder einfach immer explizit nennen).

Dies kann anderen Benutzern helfen, die diese Frage über die Erwähnung /var/pgsql_socket_alt Finden.

30
Will

Eine plausible und typische Erklärung wäre, dass das mit Homebrew gelieferte psql in /usr/local/bin/psql was sich von dem unterscheidet, der in Ihrem $ PATH wäre, wie /usr/bin/psql (im Lieferumfang von OS X enthalten). Vielleicht möchten Sie es mit dem vollständigen Pfad versuchen:

$ /usr/local/bin/psql -U Rails -d myapp_development

Außerdem gibt es in der Ausgabe von ps Ihrer Frage etwas Ungewöhnliches: Der Postgres-Server wird unter einem meltemi Unix-Benutzer ausgeführt, während im Allgemeinen der dedizierte postgres Unix-Benutzer verwendet wird dafür.

8
Daniel Vérité

Ich kenne keine Konfigurationsdatei für den psql-Client. Psql berücksichtigt jedoch eine Reihe von Umgebungsvariablen, die mit Befehlszeilenoptionen korrelieren.

Damit psql automatisch den Socket Ihrer Wahl verwendet, können Sie die Variable PGHOST auf das Verzeichnis setzen, das den Socket enthält. d.h.

PGHOST=/var/pgsql_socket_alt
psql -d mydatabsase
4
happynix

Versuchen:

psql -U Rails -d myapp_development -h localhost

oder

psql -U Rails -d myapp_development -h 127.0.0.1
3
Miguel

Spät, aber ich fand das hilfreich: http://tammersaleh.com/posts/installing-postgresql-for-Rails-3-1-on-lion

Das war für Lion, aber ich hatte die gleichen Probleme wie in diesem Thread, nachdem ich von 10.6.8 auf Mountain Lion aktualisiert und PostgreSQL zuvor über HomeBrew installiert hatte, während ich 10.6.8 hatte. Ich hatte auch den mysteriösen Ordner /var/pgsql_socket_alt Nach dem Upgrade, aber ich habe ihn einfach entfernt und /var/pgsql_socket Erstellt, wie von @wolftron vorgeschlagen. Dies war jedoch nicht die endgültige Lösung.

Wenn ich unix_socket_directory In postgresql.conf Leer gelassen/auskommentiert hätte, würden sich alle vor dem Upgrade vorhandenen Projekte darüber beschweren, dass der Socket in /var/pgsql_socket Fehlt. Aber wenn ich conf geändert und var/pgsql_socket Fest codiert hätte, würden sich alle neuen Projekte darüber beschweren, dass der Socket in /tmp Fehlt. Sehr frustrierend ... bis ich pg gem In einem Projekt vor 10.8 (gem uninstall pg && gem install pg) Neu installiert und unix_socket_directory In der Datei conf auskommentiert habe. Nach einem kurzen pg_ctl Neustart des Servers funktionierten sowohl neue als auch alte Projekte. Mein pgsql-Socket lebt jetzt in /tmp, Fwiw.

Nebenbemerkung: Wenn Sie activerecord-postgresql-adapter Gem verwenden, deinstallieren Sie es zuerst, installieren Sie pg erneut und installieren Sie dann activerecord-postgresql-adapter Erneut.

3
Foot

Ich habe mich gerade erst bei der dba SE angemeldet, daher kann ich den entsprechenden Beitrag anscheinend nicht kommentieren (was für ein Trottel!).

Ich war jedoch zuversichtlich, dass ich mich im selben Boot wie @thure befand. Ich hatte sichergestellt, dass/usr/local/bin früher in meinem PFAD war als/usr/bin, hatte überprüft, welche Binärdateien die Shell mit which und type usw. gehasht hatte.

Ich sah die gleichen Symptome wie @thure. Dann hatte ich eine Offenbarung; Mir wurde klar, dass ich das Juwel pg (ich verwende Ruby) in einer Shell neu erstellt habe, deren PATH durch Macs path_helper (der von/etc/profile ausgeführt wird und/usr/bin vor/setzt) ​​nachteilig beeinflusst wurde usr/local/bin).

Ich habe pg deinstalliert und in einer Shell neu installiert, deren PATH korrekt war. Plötzlich konnte ich mich verbinden!

Stellen Sie also sicher, dass Sie Ihre Sprachbindungs-Personen neu kompilieren und sie die richtige Kopie von (vermutlich) pg_config Finden lassen.

2
Graham Ashton

Hier ist es, 2016, El Capitan ist da draußen und Apple ändert ständig die Dinge. Postgres wird als Teil des Betriebssystems installiert, und die Postgres-Konfigurationsdatei legt die Eigenschaft unix_socket_directories in postgresql.conf fest to/tmp. Der Socket befindet sich in /tmp/.s.PGSQL.5432. Ich konnte das Problem umgehen, indem ich Folgendes ausführte:

Sudo ln -s /tmp /var/pgsql_socket

Hoffe das hilft jemandem.

1
rdiddly

Ich fand, dass das Verknüpfen des tatsächlichen Standorts mit dem erwarteten Standort einwandfrei funktioniert:

Sudo ln -s /var/pgsql_socket_alt /var/pgsql_socket

in Anlehnung an die akzeptierte Antwort von @thure, aber einfacher.

1
Danny Roberts

Ich kann den Link, über den ich dieses Nugget gefunden habe, nicht schnell finden, aber es hat bei mir funktioniert.

export PGHOST = localhost

Oh, hier ist der Link. https://stackoverflow.com/questions/13868730/socket-file-var-pgsql-socket-s-pgsql-5432-missing-in-mountain-lion-os-x-ser

1
eyemana

Suchen Sie nach der richtigen Socket-Datei

find / -name .s.PGSQL.5432 -ls

Rufen Sie aus dem Ergebnis den Pfad zur Datei ab und verwenden Sie den Pfad mit dem Parameter "-h" im Befehl psql

Auf diese Weise stelle ich beispielsweise eine Verbindung zur macOS Server-Kalender- und Kontaktdatenbank her (innerhalb einer SSH-Sitzung zum Server):

Sudo psql -U _calendar -h /private/var/run/caldavd/PostgresSocket/ -d caldav

Dann würde die Socket-Datei am Pfad verwendet, um eine Verbindung herzustellen.

1
Olaf Seifert

Ich habe diese Antwort gefunden: https://stackoverflow.com/questions/10763143/in-Rails-couldnt-create-database-for-adapter-postgresql Und so einfach es auch war, es hat funktioniert ich ... lief ein $bundle update und es fing wieder an zu arbeiten.

1
Erik Trautman

Standardmäßig scheint postgres zu versuchen, eine Verbindung über Unix-Domain-Sockets herzustellen. NIX DOMAIN SOCKET

Dies ist mir passiert, als ich eine Postgres-Instanz auf Docker ausgeführt habe. Sie müssen sehen, welche Art von Verbindung Ihr Server akzeptiert. Für mich war es eindeutig TCP und kein Unix Domain Socket.

Durch Hinzufügen eines Flags zum Akzeptieren des Hosts wurde die Verbindung zum korrekten Pfad umgeleitet und das Problem behoben.

psql -U username -p port -h Host

PS: Unix-Domain-Sockets funktionieren auf Kernel-Ebene und die Verbindung muss nicht den gesamten Jazz durchlaufen, der für TCP -Verbindungen) erforderlich ist. Sie sind ziemlich schnell und effizient, wenn Sie eine Verbindung zu Ihrem herstellen möchten eigene Maschine aus einem anderen Prozess als Teil der Interprozesskommunikation.

1
Sudip Bhandari

Ich habe den gleichen Fehler beim Versuch, psql in der Befehlszeile auszuführen. Es stellte sich heraus, dass meine Lösung viel einfacher war. Ich habe den Überwachungsport in der Konfigurationsdatei falsch konfiguriert: /etc/postgresql/9.4/main/postgres.conf . Ich hatte den Port von Port = 5432 in Port = 5433 geändert. Als ich ihn wieder in 5432 änderte, funktionierte er wie erwartet.

Um zu testen, ob Sie etwas Ähnliches getan haben, können Sie $ psql -p5433 Es gibt eine Reihe nützlicher Optionen wie diese für den Befehl psql, die Sie hier finden: http://www.postgresql.org/docs/9.4/static/app-psql.html so dass Sie Ihre EIGENE Fehlkonfiguration testen können. Natürlich können Sie auch Ihre letzten Konfigurationsänderungen einfach aus den * .conf-Dateien entfernen, um zu testen, ob diese die Ursache Ihres Problems sind. Ich denke, es lohnt sich auf jeden Fall, einen Blick darauf zu werfen, bevor Sie sich mit Dateiberechtigungen und Eigentumsrechten beschäftigen. (Vergiss nur nicht, /etc/init.d/postgresql restart)

Was ich NICHT finden konnte, war die Konfigurationsdatei, die die Standardwerte für den Befehl psql CLI festlegt. Kann das bitte jemand kommentieren?

Für mich kehre ich immer zu meinem ersten Prinzip der Programmierung zurück: "Ich bin normalerweise die Quelle eines bestimmten Fehlers!"

0