PostgreSQL działa lokalnie, ale nie mogę się połączyć. Czemu?

32

Niedawno zaktualizowałem moją maszynę z Mac OS X Lion (10.7.4) do Mountain Lion (10.8) i myślę, że to zepsuło moją instalację PostgreSQL. Został on zainstalowany pierwotnie przez Homebrew. Nie jestem DBA, ale mam nadzieję, że ktoś powie mi, jak rozwiązać ten problem.

Nie mogę się połączyć (ale mogłem to zrobić przed Lion 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"?

Ale Postgres nadal działa:

$ 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

Odpowiada na zapytania (zarówno do testowej bazy danych, jak i bazy danych programisty) z lokalnej aplikacji Rails

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

Wygląda na to, że nie ma /var/pgsql_socket/katalogu, a co dopiero /var/pgsql_socket/.s.PGSQL.5432wspomnianego wyżej pliku gniazda!?! Być może instalacja Mountain Lion usunęła to?

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

Jak mogę rozwiązać ten problem?

Meltemi
źródło
Nie jest administratorem postgres, ale brakujący plik gniazda brzmi dobrze. Utwórz katalog / var / pgsql_socket (z uprawnieniami użytkownika do zapisu) i zrestartuj serwer. Sprawdź, czy to naprawi
Derek Downey,
Powiązane pytanie dotyczące SO . Wygląda na to, że Apple nie wykonało świetnej pracy z aktualizacją.
Erwin Brandstetter
czy w pliku dziennika jest mowa o tworzeniu pliku gniazda /usr/local/var/postgres/server.log?
Philᵀᴹ
@ErwinBrandstetter Jak oczekujesz, że Apple wykona „dobrą robotę”, aktualizując ręcznie instalowane aplikacje * nix innych firm?
Philᵀᴹ
@ Phil- brak wzmianki. Zaczynam myśleć, że to może być problem zmiennej ścieżki. Myślę, że mój $PATHzostał zmieniony z uaktualnieniem /usr/binjest przed /usr/local/bini myślę, że Mountain Lion mogą pochodzić z PostgreSQL pre-instalowany!?! Dochodzenie ...
Meltemi

Odpowiedzi:

30

Odkryłem, że mam bardzo podobny problem, mianowicie, że postgres otwierał gniazdo, w /var/pgsql_socket_altktórym żadne z moich programów nie oczekuje, ale rozwiązanie mojego problemu było nie tylko moim problemem $PATH.

Musiałem stworzyć katalog /var/pgsql_socketchown to dla siebie, a zestaw unix_socket_directoryw postgresql.conf(znajduje się /usr/local/var/postgres) do tego katalogu, a następnie użyć pg_ctlpliku binarnego w /usr/local/bincelu uruchomienia odpowiedniego serwera postgres'owy sukcesem (czyli tam, gdzie $PATHprzychodzi - upewnij się, which pg_ctlpostanawia /usr/local/bin/pg_ctl, lub po prostu zawsze nazwij to jawnie).

Może to pomóc innym użytkownikom, którzy znajdą to pytanie poprzez /var/pgsql_socket_altwzmiankę.

Wola
źródło
Ciekawy. Czy ty też jesteś na Mountain Lion? Czy zainstalowałeś PostgreSQL z Homebrew? Jeśli tak, zastanawiaj się, czy ktoś inny może zweryfikować to rozwiązanie, a nie zmienić moje, $PATHtak jak ja.
Meltemi
Tak, tak i mam taką nadzieję!
Czy
@wolftron twoje rozwiązanie było dla mnie hukiem (Mountain Lion, homebrew / postgres, / var / pgsql_socket_alt, całe dziewięć). Czy to nowy problem w Mountain Lion z Homebrew? Otworzę z nimi bilet, jeśli tak uważasz.
Wygląda na to, że mamy weryfikację od @Jamie.
Czy
Mogę potwierdzić ten problem i rozwiązanie w systemie OS X 10.8.2 / brew instalacji postgresql 9.2.1.
Hartwig
8

Prawdopodobnym i typowym wyjaśnieniem byłoby to, że ten, psqlktóry pochodzi z homebrew, /usr/local/bin/psqlróżni się od tego, który byłby w twojej $ PATH, na przykład /usr/bin/psql(w pakiecie z OS X). Możesz spróbować z pełną ścieżką:

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

Jest też coś niezwykłego w pswynikach twojego pytania: serwer Postgres działa pod meltemiużytkownikiem Unixa, podczas gdy postgresdo tego celu służy dedykowany użytkownik Unixa.

Daniel Vérité
źródło
Również _postgres(z podkreśleniem) dla użytkownika / grupy nie są mi znane. Czy to artefakt, czy się go spodziewamy?
Erwin Brandstetter
Tak, jak powiedziałeś, wydaje się to być $PATHproblemem. Wszystko działa jak poprzednio, kiedy korzystam /usr/local/bin/psqlz dostępu do bazy danych. Albo Lion nie miał systemu PostgreSQL, albo moja $ PATH została skonfigurowana inaczej. Minął rok, odkąd po raz ostatni się z tym pogubiłem, więc nie pamiętam dokładnie. Jeśli chodzi o użytkownika Unix ... z instalacją PostgreSQL Homebrew, serwer jest uruchamiany przez uruchomienie, a użytkownik jest ustawiony domyślnie na lokalnego użytkownika, który go zainstalował. Sprawy są skonfigurowane inaczej na Mac OS X Server, który automatycznie uruchamia PostgreSQL pod postgres.
Meltemi
4

Nie znam żadnego pliku konfiguracyjnego dla klienta psql. Jednak psql respektuje wiele zmiennych środowiskowych, które korelują z opcjami wiersza poleceń.

Aby więc psql automatycznie używał wybranego gniazda, możesz ustawić zmienną PGHOST na katalog zawierający gniazdo. to znaczy

PGHOST=/var/pgsql_socket_alt
psql -d mydatabsase
happynix
źródło
1
Nigdzie nie udokumentowano, że można ustawić PGHOST w katalogu, w którym znajdują się pliki gniazd. Ale to w rzeczywistości działa. Dzięki!
Andrew Schulman
3

Próbować:

psql -U rails -d myapp_development -h localhost

lub

psql -U rails -d myapp_development -h 127.0.0.1
Miguel
źródło
3

Późno, ale uznałem to za pomocne: http://tammersaleh.com/posts/installing-postgresql-for-rails-3-1-on-lion

To było dla Lion, ale miałem problemy z tym w tym wątku po aktualizacji z 10.6.8 do Mountain Lion i zainstalowaniu PostgreSQL przez HomeBrew wcześniej na 10.6.8. Po /var/pgsql_socket_altuaktualnieniu miałem również tajemniczy folder, ale właśnie go usunąłem i utworzyłem /var/pgsql_socketzgodnie z sugestią @wolftron. Nie było to jednak ostateczne rozwiązanie.

Gdybym pozostawił unix_socket_directorypuste / skomentowane w postgresql.conf, wszelkie projekty istniejące przed aktualizacją skarżyłyby się na /var/pgsql_socketbrakujące gniazdo . Ale gdybym zmienił conf i zakodował na stałe var/pgsql_socket, wszelkie nowe projekty narzekałyby na brak gniazda /tmp. Bardzo frustrujące ... dopóki nie zainstalowałem ponownie pg gemw projekcie wcześniejszym niż 10.8 ( gem uninstall pg && gem install pg) i nie unix_socket_directoryskomentowałem w confpliku. Po szybkim pg_ctlzrestartowaniu serwera działały zarówno nowe, jak i stare projekty. Moje gniazdo pgsql /tmpjuż istnieje, fwiw.

Uwaga: jeśli używasz activerecord-postgresql-adapterklejnotu, najpierw go odinstaluj, a następnie ponownie zainstaluj pg, a następnie zainstaluj activerecord-postgresql-adapterponownie.

Stopa
źródło
2

Właśnie zarejestrowałem się w dba SE, więc nie wydaje mi się, aby móc komentować odpowiedni post (co za bzdura!).

Byłem jednak pewien, że byłem na tej samej łodzi co @ thure. Bym upewnił / usr / local / bin został wcześniej niż w moim PATH / usr / bin, który sprawdził binarne powłoka miał mieszany z whichi typeitp

Widziałem te same objawy, co @ture. Potem miałem objawienie; Uświadomiłem sobie, że odbudowałem pgklejnot (używam Ruby) w powłoce, na PATH niekorzystnie wpłynął path_helper Maca (który jest uruchamiany z / etc / profile i umieszcza / usr / bin przed / usr / local / bin) .

Odinstalowałem pg i ponownie zainstalowałem go w powłoce, której ŚCIEŻKA była poprawna. Nagle mogłem się połączyć!

Upewnij się więc, że ponownie skompilujesz swoje powiązania językowe i pozwól im znaleźć poprawną kopię (prawdopodobnie) pg_config.

Graham Ashton
źródło
1

Przekonałem się, że symlinkowanie rzeczywistej lokalizacji do oczekiwanej lokalizacji działa dobrze:

sudo ln -s /var/pgsql_socket_alt /var/pgsql_socket

zgodnie z przyjętą odpowiedzią @, ale prostsze.

Danny Roberts
źródło
1

Oto rok 2016, El Capitan jest na rynku, a Apple ciągle coś zmienia. Postgres jest instalowany jako część systemu operacyjnego, a plik konfiguracyjny postgres ustawia właściwość unix_socket_directories w postgresql.conf na / tmp. Gniazdo znajduje się w /tmp/.s.PGSQL.5432. Byłem w stanie obejść ten problem, wykonując następujące czynności:

sudo ln -s /tmp /var/pgsql_socket

Mam nadzieję, że to komuś pomoże.

niechlujnie
źródło
1

Poszukaj poprawnego pliku gniazda

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

Z wyniku uzyskaj ścieżkę do pliku i użyj ścieżki z parametrem „-h” w komendzie psql

Na przykład w ten sposób łączę się z bazą danych kalendarza i kontaktów serwera macOS (w ramach sesji ssh z serwerem):

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

Następnie do połączenia wykorzystany zostanie plik gniazda przy ścieżce.

Olaf Seifert
źródło
1

Domyślnie postgres wydaje się próbować połączyć przez gniazda domeny unix. GNIAZDO DOMENOWE UNIX

Zdarzyło mi się to, gdy uruchomiłem instancję postgres w oknie dokowanym. Musisz zobaczyć, jaki rodzaj połączenia akceptuje Twój serwer. Dla mnie było to wyraźnie TCP, a nie unixowe gniazdo domeny.

Dodanie flagi, aby zaakceptować host przekierowało połączenie do poprawnej ścieżki i rozwiązało problem.

psql -U username -p port -h host

PS: Gniazda domen Unix działają na poziomie jądra, a połączenie nie musi przejść całego jazzu wymaganego do połączeń TCP. Są dość szybkie i wydajne, gdy chcesz nawiązać połączenie z własną maszyną na podstawie innego procesu w ramach komunikacji międzyprocesowej.

Sudip Bhandari
źródło
0

Witaj świecie :)
Najlepszym, ale dziwnym sposobem dla mnie było robienie kolejnych rzeczy.

1) Pobierz postgres93.app lub inną wersję. Dodaj tę aplikację do folderu / Applications /.

2) Dodaj wiersz (polecenie) do pliku .bash_profile(który znajduje się w moim katalogu domowym):

eksport PATH = / Aplikacje / Postgres93.app / Contents / MacOS / bin /: $ PATH
To droga do psqlz Postgres93.app. Wiersz (polecenie) jest uruchamiany przy każdym uruchomieniu konsoli.

3) Uruchom Postgres93.appz /Applications/folderu. Uruchamia serwer lokalny (port to „5432”, a host to „localhost”).

4) Po tych wszystkich manipulacjach z przyjemnością uruchomiłem $ createuser -SRDP user_nameinne polecenia i zobaczyłem, że zadziałało! Postgres93.appmoże być uruchamiany przy każdym uruchomieniu systemu.

5) Również jeśli chcesz zobaczyć swoje bazy danych graficznie, powinieneś zainstalować PG Commander.app. To dobry sposób, aby zobaczyć swoją bazę danych postgres jako ładne tabele danych

Oczywiście jest to przydatne tylko dla lokalnego serwera. Będę zadowolony, jeśli te instrukcje pomogą innym, którzy napotkali ten problem.

crazzyaka
źródło
0

Ten sam błąd wystąpił podczas próby uruchomienia psqlw wierszu polecenia. Okazało się, że moje rozwiązanie było znacznie prostsze. Źle skonfigurowałem port nasłuchujący w pliku konfiguracyjnym: /etc/postgresql/9.4/main/postgres.conf . Zmieniłem port z portu = 5432 na port = 5433. Kiedy zmieniłem go z powrotem na 5432, działał zgodnie z oczekiwaniami.

Aby sprawdzić, czy zrobiłeś coś podobnego, możesz uruchomić $ psql -p5433 Istnieje wiele przydatnych opcji takich jak ta dla komendy psql, które można znaleźć tutaj: http://www.postgresql.org/docs/9.4/static/app-psql .html , abyś mógł przetestować swoją własną błędną konfigurację. Oczywiście możesz po prostu usunąć ostatni zestaw zmian konfiguracji również z plików * .conf, aby sprawdzić, czy to one są przyczyną Twojego problemu. Myślę, że z pewnością warto to sprawdzić, zanim przejdziesz z uprawnieniami do plików i prawami własności. (Tylko nie zapomnij /etc/init.d/postgresql restart)

NIE mogłem znaleźć pliku konfiguracyjnego, który ustawia wartości domyślne dla komendy CLI psql. Czy ktoś może to skomentować?

Dla mnie zawsze wracam do mojej pierwszej zasady programowania: „Zwykle jestem źródłem każdego błędu!”

MożeWeAreAllRobots
źródło