PostgreSQL fonctionne localement mais je ne peux pas me connecter. Pourquoi?
Récemment mis à jour ma machine de Mac OS X Lion (10.7.4) à Mountain Lion (10.8) et je pense que cela a falsifié mon installation PostgreSQL. Il a été installé à l'origine via Homebrew. Je ne suis pas un DBA, mais j'espère que quelqu'un pourra me dire comment résoudre ce problème.
Je n'arrive pas à me connecter (mais j'ai pu le faire avant Mountain Lion):
$ 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"?
Mais Postgres fonctionne toujours clairement:
$ 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
Et il répond aux requêtes (à la fois à une base de données de test et à la base de données de développement) à partir d'une application locale Rails
User Load (0.2ms) SELECT "users".* FROM "users"
Rendered users/index.html.haml within layouts/application (1.3ms)
Il semble qu'il n'y ait pas de /var/pgsql_socket/ répertoire, sans parler du /var/pgsql_socket/.s.PGSQL.5432 fichier socket mentionné ci-dessus!?! Peut-être que l'installation de Mountain Lion a effacé cela?
$ ls -l /var/ | grep pg
drwxr-x--- 2 _postgres _postgres 68 Jun 20 16:39 pgsql_socket_alt
Comment puis-je résoudre ce problème?
J'ai trouvé que j'avais un problème extrêmement similaire, à savoir que postgres ouvrait un socket dans /var/pgsql_socket_alt où aucun de mes logiciels ne s'attend à voir, mais la solution à mon problème n'était pas seulement un problème avec mon $PATH.
J'ai dû créer le répertoire /var/pgsql_socket, montrez-le moi-même et définissez unix_socket_directory dans postgresql.conf (situé dans /usr/local/var/postgres) dans ce répertoire, puis utilisez le pg_ctl binaire dans /usr/local/bin pour démarrer correctement le bon serveur postgres (c'est là que $PATH entre - assurez-vous que which pg_ctl se résout en /usr/local/bin/pg_ctl, ou tout simplement l'appeler explicitement).
Cela pourrait aider d'autres utilisateurs qui trouvent cette question via le /var/pgsql_socket_alt mention.
Une explication plausible et typique serait que le psql fourni avec l'homebrew est dans /usr/local/bin/psql qui est différent de celui qui serait dans votre $ PATH, comme /usr/bin/psql (fourni avec OS X). Vous voudrez peut-être essayer avec le chemin complet:
$ /usr/local/bin/psql -U Rails -d myapp_development
De plus, il y a quelque chose d'assez inhabituel dans la sortie ps de votre question: le serveur postgres fonctionne sous un utilisateur Unix meltemi, alors qu'en général, l'utilisateur Unix postgres dédié est utilisé pour ça.
Je ne connais aucun fichier de configuration pour le client psql. Cependant, psql respecte un certain nombre de variables d'environnement en corrélation avec les options de ligne de commande.
Donc, pour que le psql utilise automatiquement le socket de votre choix, vous pouvez définir la variable PGHOST dans le répertoire contenant le socket. c'est à dire.
PGHOST=/var/pgsql_socket_alt
psql -d mydatabsase
Essayer:
psql -U Rails -d myapp_development -h localhost
ou
psql -U Rails -d myapp_development -h 127.0.0.1
Tard, mais j'ai trouvé cela utile: http://tammersaleh.com/posts/installing-postgresql-for-Rails-3-1-on-lion
C'était pour Lion, mais je rencontrais les mêmes problèmes que celui de ce fil après la mise à niveau de 10.6.8 vers Mountain Lion et après avoir installé PostgreSQL via HomeBrew sur 10.6.8. J'ai aussi eu le mystérieux /var/pgsql_socket_alt dossier après la mise à niveau, mais je viens de le supprimer et de créer /var/pgsql_socket comme suggéré par @wolftron. Cependant, ce n'était pas la solution finale.
Si je quittais unix_socket_directory vide/commenté dans postgresql.conf, tout projet existant avant la mise à niveau se plaindrait que le socket dans /var/pgsql_socket manquait. Mais si j'ai changé de conf et codé en dur var/pgsql_socket, tout nouveau projet se plaindrait que le socket dans /tmp manquait. Très frustrant ... jusqu'à ce que je réinstalle pg gem dans un projet antérieur à 10.8 (gem uninstall pg && gem install pg) et gauche unix_socket_directory mis en commentaire dans le fichier conf. Après un rapide pg_ctl pour redémarrer le serveur, les nouveaux et les anciens projets ont fonctionné. Mon socket pgsql vit dans /tmp maintenant, fwiw.
Sidenote: si vous utilisez activerecord-postgresql-adapter gem, désinstallez-le d'abord, puis réinstallez pg, puis installez activerecord-postgresql-adapter encore.
Je viens juste de m'inscrire à la dba SE, alors ne semble pas être en mesure de commenter le post pertinent (quel crock!).
Cependant, j'étais confiant que j'étais dans le même bateau que @thure. Je m'étais assuré que/usr/local/bin était plus tôt dans mon CHEMIN que/usr/bin, j'avais vérifié quels binaires le Shell avait hachés avec which et type, etc.
J'ai vu les mêmes symptômes que @thure. Ensuite, j'ai eu une révélation; J'ai réalisé que j'avais reconstruit la gemme pg (j'utilise Ruby) dans un Shell dont le CHEMIN avait été affecté par path_helper de Mac (qui est exécuté depuis/etc/profile et place/usr/bin avant/usr/local/bin).
J'ai désinstallé pg et l'ai réinstallé dans un shell dont le CHEMIN était correct. Tout d'un coup, j'ai pu me connecter!
Assurez-vous donc de recompiler les personnes de votre langage et laissez-les trouver la copie correcte de (vraisemblablement) pg_config.
Le voici, 2016, El Capitan est là-bas, et Apple continue de changer les choses. Postgres est installé dans le cadre du système d'exploitation, et le fichier de configuration postgres définit la propriété unix_socket_directories dans postgresql.conf dans/tmp. Le socket est dans /tmp/.s.PGSQL.5432. J'ai pu contourner le problème en exécutant ce qui suit:
Sudo ln -s /tmp /var/pgsql_socket
J'espère que cela aide quelqu'un.
J'ai trouvé que le lien symbolique entre l'emplacement réel et l'emplacement prévu fonctionnait très bien:
Sudo ln -s /var/pgsql_socket_alt /var/pgsql_socket
dans le sens de la réponse acceptée par @thure mais plus simple.
Je ne trouve pas rapidement le lien où j'ai trouvé cette pépite, mais cela a fonctionné pour moi.
export PGHOST = localhost
Oh, voici le lien. https://stackoverflow.com/questions/13868730/socket-file-var-pgsql-socket-s-pgsql-5432-missing-in-mountain-lion-os-x-ser
Recherchez le bon fichier de socket
find / -name .s.PGSQL.5432 -ls
À partir du résultat, obtenez le chemin d'accès au fichier et utilisez le chemin d'accès avec le paramètre "-h" dans la commande psql
Par exemple, voici la façon dont je me connecte à la base de données Calendrier et Contacts du serveur macOS (dans une session ssh sur le serveur):
Sudo psql -U _calendar -h /private/var/run/caldavd/PostgresSocket/ -d caldav
Ensuite, le fichier socket sur le chemin serait utilisé pour se connecter.
J'ai trouvé cette réponse: https://stackoverflow.com/questions/10763143/in-Rails-couldnt-create-database-for-adapter-postgresql Et, aussi simple soit-il, cela a fonctionné pour moi ... a couru un $bundle update et il a recommencé à fonctionner.
Par défaut, postgres semble essayer de se connecter via unix-domain-sockets. PRISE DE DOMAINE UNIX
Cela m'est arrivé lorsque j'exécutais l'instance postgres sur docker. Vous devez voir quel type de connexion votre serveur accepte. Pour moi, c'était clairement TCP et non la socket de domaine Unix.
L'ajout d'un indicateur pour accepter l'hôte a redirigé la connexion vers le chemin correct et résolu le problème.
psql -U username -p port -h Host
PS: les sockets de domaine Unix fonctionnent au niveau du noyau et la connexion n'a pas à passer par tout le jazz requis pour les connexions TCP. Elles sont assez rapides et efficaces lorsque vous souhaitez vous connecter à votre propre machine à partir d'un processus différent dans le cadre de la communication interprocessus.
J'ai obtenu cette même erreur en essayant d'exécuter psql sur la ligne de commande. Il s'est avéré que ma solution était beaucoup plus simple. J'avais mal configuré le port d'écoute dans le fichier de configuration: /etc/postgresql/9.4/main/postgres.conf . J'avais changé le port de port = 5432 en port = 5433. Quand je l'ai changé de nouveau en 5432, cela a fonctionné comme prévu.
Pour tester si vous avez fait quelque chose de similaire, vous pouvez exécuter $ psql -p5433 Il existe un certain nombre d'options utiles comme celle-ci pour la commande psql que vous pouvez trouver ici: http://www.postgresql.org/docs/9.4/static/app-psql.html so que vous pouvez tester votre propre configuration incorrecte. Bien sûr, vous pouvez également simplement supprimer votre dernier ensemble de modifications de configuration des fichiers * .conf, pour tester si elles sont à l'origine de votre problème. Je pense qu'il vaut certainement la peine de vérifier avant de se moquer des autorisations et des propriétaires de fichiers. (N'oubliez pas de /etc/init.d/postgresql restart)
Ce que je n'ai PAS pu trouver, c'est le fichier de configuration qui définit les valeurs par défaut de la commande psql CLI. Quelqu'un peut-il commenter cela, s'il vous plaît?
Pour moi, je reviens toujours à mon premier principe de programmation: "Je suis généralement la source d'une erreur donnée!"