Ho appena reinstallato Postgres tramite brew install postgres

Ho corso initdb /usr/local/var/postgres -E utf8ma ho ottenuto questo:

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".

così, ho rm -rfla cartella postgres e l' ho eseguita di nuovo:

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

diceva che tutto andava bene:

Success. You can now start the database server using:

    postgres -D /usr/local/var/postgres

così, ho eseguito quel comando e ho ottenuto:

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"?

Ora, quando guardo il mio Activity Monitor, vedo 6 istanze di postgress.

Come posso risolvere questo problema?

Annuncio di servizio pubblico: mai cancellare postmaster.pid. Veramente. Ottimo modo per ottenere il danneggiamento dei dati.

PostgreSQL era già installato e hai eliminato la directory dei dati senza arrestare il server in esecuzione. Quindi ora hai alcuni processi orfani del server PostgreSQL che gestiscono i file di dati che sono stati eliminati, quindi non sono più accessibili nel file system e verranno completamente eliminati quando verrà chiuso l'ultimo file aperto gestito da loro. Non è possibile utilizzare pg_ctlper arrestare il server come di consueto perché è stato eliminato il datadir del cluster, quindi è sufficiente interrompere i processi. Uccidi il postmaster ( non usare kill -9, lo farà solo una normale uccisione) e anche il resto si spegnerà.

Sarai quindi in grado di avviare un nuovo server nel datadir con i initdbdati appena aggiornati .

È molto probabile che si verifichino conflitti lungo la strada se non si disinstalla l'altra versione precedente di PostgreSQL.

In breve:

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

Annota il numero sulla prima riga, che è il pid del postmaster.

Verifica psche il pid sia quello di un postmaster postgres.

Uccidi il processo postmaster con il seguente comando, sostituendo "PID" con il numero che hai annotato. Ancora una volta, non usare kill -9o kill -KILL, basta usare un semplice kill, cioè unSIGTERM :

kill PID

Se il pid non è quello di un postmaster postgres, manualmente killtutti i postgresback-end che potrebbero essere ancora in esecuzione, verificare che non siano più in esecuzione e solo successivamente rimuoverli postmaster.pid. (È inoltre necessario verificare che postmaster.pidnon sia presente nella memoria condivisa in cui il server potrebbe essere in esecuzione su un'altra VM / host).

Un'altra possibilità è che tu abbia avuto un duro arresto e che il processo postgres sia morto senza ripulire il suo file pid. Questo succede a me quando la batteria del mio laptop si scarica.

Questa soluzione non è per un sistema di produzione e dovresti davvero assicurarti che il demone Postgres non sia in esecuzione , ma io uso il mio laptop per la codifica e non sono preoccupato di dover rigenerare i miei database.

Quindi, se un altro processo - o nessuno del tutto - è in esecuzione su quella porta, basta eliminare il file pid, ad es

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

e presto Postgres inizierà bene.

Per scoprire se un altro processo è in esecuzione su quella porta, puoi farlo

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

Quindi corri

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

per vedere se ha funzionato. Tu dovresti vedere

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

(o almeno è quello che ho appena visto dopo aver fatto quanto sopra :-))

(E davvero, Postgres non dovrebbe essere abbastanza intelligente da rendersi conto che non esiste un processo con PID 933 e rimuovere il file pid fasullo da solo?)

Ho provato tutto questo inutilmente dopo l'aggiornamento a Yosemite ha rotto i miei postgres (installato tramite homebrew).

Poi mi sono imbattuto in questo post del blog: http://ruckus.tumblr.com/post/100355276496/yosemite-upgrade-breaks-homebrew-installed-postgres

Per prima cosa ho dovuto creare le directory mancanti apparentemente cancellate durante l'aggiornamento (grazie Apple!).

$ cd /usr/local/var/postgres

$ mkdir {pg_tblspc,pg_twophase,pg_stat_tmp}

Quindi riavvia Postgres usando la normale sequenza di avvio di homebrew:

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

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

Grazie Ruckus Notes per avermi aiutato a risolvere il mio problema. Spero che ti aiuti anche tu.

ISTRUZIONI DI RIAVVIO DURO

Ho avuto lo stesso problema dopo un riavvio difficile. Dopo aver verificato il postmaster.pidpid del file, ho notato che non avevo alcun processo in esecuzione. Non volevo cancellare a fondo il file .pid, invece ho usato un pg-stopalias che avevo creato nel mio .bash_profile. questo alias funziona

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

Per riferimento

# 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'

dopo l'uscita 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

infuso

Ho pensato che dovrei anche menzionare qui che se hai installato Postgres con homebrew dovresti dare brew servicesun'occhiata. Questo è il modo in cui preferisco avviare / arrestare i miei database.

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

Ho ricevuto questo errore dopo, credo, il mio computer si è bloccato. PostgreSQL non ha potuto nemmeno avviarsi a causa di questo errore, quindi uccidere il processo non era la soluzione. Ho semplicemente eseguito il backup e quindi eliminato il postmaster.pidfile e quindi l'errore si è fermato e PG è stato in grado di ricominciare.

A volte l'umile pg_ctl -w restartpuò fare il trucco :-)

L'eliminazione di postmaster.pid è in realtà una cosa davvero decente da fare ad ogni avvio, alla cieca. Questo è ciò che fa il mio sistema. Poiché hai appena avviato, sai che non esiste alcun processo Postgres in esecuzione e se ti stai riprendendo da un arresto impuro, questo file sarà lì che impedisce il recupero.

Una progettazione migliore per Postgres sarebbe quella di inserire il file postmaster.pid nel filesystem / run, quindi è garantito che venga eliminato ad ogni riavvio. Molti altri server funzionano in questo modo.