Właśnie przeinstalowałem postgres przez brew install postgres

Pobiegłem, initdb /usr/local/var/postgres -E utf8ale dostałem to:

The files belonging to this database system will be owned by user "atal421".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default text search configuration will be set to "english".

initdb: directory "/usr/local/var/postgres" exists but is not empty
If you want to create a new database system, either remove or empty
the directory "/usr/local/var/postgres" or run initdb
with an argument other than "/usr/local/var/postgres".

więc mam rm -rffolder postgres i uruchomiłem go ponownie:

 initdb /usr/local/var/postgres -E utf8

powiedziało, że wszystko jest w porządku:

Success. You can now start the database server using:

    postgres -D /usr/local/var/postgres

więc uruchomiłem to polecenie i otrzymałem:

postgres -D /usr/local/var/postgres


FATAL:  lock file "postmaster.pid" already exists
HINT:  Is another postmaster (PID 13731) running in data directory "/usr/local/var/postgres"?

Teraz, gdy patrzę na monitor aktywności, widzę 6 wystąpień adresu pocztowego.

Jak to naprawić?

Ogłoszenie o usługach publicznych: nigdy nie usuwaj postmaster.pid. Naprawdę. Świetny sposób na uszkodzenie danych.

Masz już zainstalowany PostgreSQL i usunąłeś katalog danych bez zatrzymywania działającego serwera. Masz teraz niektóre osierocone procesy serwera PostgreSQL, które zarządzają usuniętymi plikami danych, więc nie są one już dostępne w systemie plików i zostaną całkowicie usunięte, gdy ostatni otwarty uchwyt pliku zostanie zamknięty. Nie można użyć pg_ctldo zamknięcia serwera w normalny sposób, ponieważ usunąłeś katalog danych klastra, więc musisz po prostu zabić procesy. Zabij postmastera ( nie używaj kill -9, wystarczy zwykłe zabójstwo), a reszta też się wyłączy.

Będziesz wtedy mógł uruchomić nowy serwer w katalogu danych w oparciu o świeżo initdbzapisane dane.

Jest wysoce prawdopodobne, że wystąpią konflikty na późniejszym etapie, chyba że odinstalujesz inną starszą wersję PostgreSQL.

W skrócie:

cat /usr/local/var/postgres/postmaster.pid

Zanotuj numer w pierwszym wierszu, który jest pid postmistrza.

Sprawdź ps, czy pid to postmaster postmaster.

Zabij proces postmastera następującą komendą, zastępując „PID” numerem, który zanotowałeś. Ponownie, nie używaj kill -9lub kill -KILLpo prostu używaj zwykłego kill, tj .SIGTERM :

kill PID

Jeśli pid nie jest postmasterem postmastera, ręcznie uruchom killwszystkie postgresbackendy, które mogą nadal działać, sprawdź , czy już nie działają, a dopiero potem usuń postmaster.pid. (Należy również sprawdzić, czy postmaster.pidnie znajduje się on w pamięci współdzielonej, na której serwer mógłby działać na innej maszynie wirtualnej / hoście).

Inną możliwością jest to, że mocno się zamknąłeś i proces postgres zmarł bez czyszczenia pliku pid. Zdarza mi się to, gdy bateria mojego laptopa wyczerpuje się.

To rozwiązanie nie jest przeznaczone dla systemu produkcyjnego i powinieneś naprawdę upewnić się, że demon Postgres nie działa , ale używam mojego laptopa do kodowania i nie martwię się o konieczność zregenerowania moich baz danych.

Więc jeśli na tym porcie działa inny proces - lub wcale go nie ma - po prostu usuń plik pid, np

rm /usr/local/var/postgres/postmaster.pid

i postgres wkrótce zacznie działać dobrze.

Aby dowiedzieć się, czy na tym porcie działa inny proces, możesz to zrobić

ps wax | grep `head -1 /usr/local/var/postgres/postmaster.pid`

Następnie uruchomić

tail -f /usr/local/var/postgres/server.log 

aby sprawdzić, czy zadziałało. Powinieneś zobaczyć

FATAL:  lock file "postmaster.pid" already exists
HINT:  Is another postmaster (PID 933) running in data directory "/usr/local/var/postgres"?
FATAL:  lock file "postmaster.pid" already exists
HINT:  Is another postmaster (PID 933) running in data directory "/usr/local/var/postgres"?
LOG:  database system was interrupted; last known up at 2014-05-25 09:41:32 PDT
LOG:  database system was not properly shut down; automatic recovery in progress

(a przynajmniej tak właśnie zobaczyłem po wykonaniu powyższego :-))

(I naprawdę, czy Postgres nie powinien być wystarczająco inteligentny, aby zdać sobie sprawę, że PID 933 nie ma procesu i sam usunąć fałszywy plik pid?)

Próbowałem tego wszystkiego bezskutecznie po aktualizacji do Yosemite złamał mój postgres (zainstalowany przez homebrew).

Potem natknąłem się na ten post na blogu: http://ruckus.tumblr.com/post/100355276496/yosemite-upgrade-breaks-homebrew-installed-postgres

Najpierw musiałem utworzyć brakujące katalogi, które najwyraźniej zostały usunięte podczas aktualizacji (dzięki Apple!).

$ cd /usr/local/var/postgres

$ mkdir {pg_tblspc,pg_twophase,pg_stat_tmp}

Następnie ponownie uruchom postgres, używając normalnej sekwencji uruchamiania homebrew:

$ launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

$ launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

Dzięki Ruckus Notes za pomoc w rozwiązaniu mojego problemu. Mam nadzieję, że to również pomaga.

TWARDE INSTRUKCJE REBOOTU

Miałem ten sam problem po ciężkim ponownym uruchomieniu. Po sprawdzeniu postmaster.pidpid pliku zauważyłem, że nie mam uruchomionego procesu. Nie chciałem mocno usuwać pliku .pid, zamiast tego użyłem pg-stopaliasu, który utworzyłem w swoim .bash_profile. ten alias po prostu działa

pg_ctl -D /usr/local/var/postgres stop -s -m fast

Na przykład

# psql
alias pg-start='pg_ctl -D /usr/local/var/postgres -l /usr/local/var/postgres/server.log start'
alias pg-stop='pg_ctl -D /usr/local/var/postgres stop -s -m fast'

dane wyjściowe dziennika po pg-stop

LOG:  database system was interrupted; last known up at 2016-04-25 10:51:08 PDT
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/274FA10
LOG:  redo is not required
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
LOG:  received smart shutdown request
LOG:  autovacuum launcher shutting down
LOG:  shutting down
LOG:  database system is shut down
LOG:  database system was shut down at 2016-04-25 13:11:04 PDT

napar

Pomyślałem, że powinienem tutaj również wspomnieć, że jeśli zainstalowałeś postgres z homebrew, powinieneś rzucić brew servicesokiem. W ten sposób wolę uruchamiać / zatrzymywać moje bazy danych.

XXXXX:~ chris$ brew services list
Name       Status  User  Plist
mongodb    stopped
postgresql started chris /Users/chris/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
redis      started chris /Users/chris/Library/LaunchAgents/homebrew.mxcl.redis.plist

Ten błąd wystąpił po, jak sądzę, awarii mojego komputera. PostgreSQL nie mógł nawet uruchomić z powodu tego błędu, więc zabicie procesu nie było rozwiązaniem. Po prostu utworzyłem kopię zapasową, a następnie usunąłem postmaster.pidplik, a następnie błąd ustał i PG mógł rozpocząć od nowa.

Czasami pokorni pg_ctl -w restartmogą załatwić sprawę :-)

Usuwanie postmaster.pid jest naprawdę całkiem przyzwoitą rzeczą do zrobienia przy każdym rozruchu, na ślepo. Tak właśnie działa mój system. Ponieważ właśnie się uruchomiłeś, wiesz, że nie ma uruchomionego procesu Postgres, a jeśli odzyskujesz po nieczystym zamknięciu, ten plik będzie tam uniemożliwiać odzyskiwanie.

Lepszym rozwiązaniem dla Postgresa byłoby umieszczenie pliku postmaster.pid w systemie plików / run, więc gwarantuje się, że zostanie usunięty przy każdym ponownym uruchomieniu. Wiele innych serwerów działa w ten sposób.