Acabo de reinstalar postgres a través de brew install postgres

Corrí initdb /usr/local/var/postgres -E utf8pero obtuve esto:

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

entonces, yo rm -rfla carpeta postgres y la ejecuté nuevamente:

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

decía que todo estaba bien:

Success. You can now start the database server using:

    postgres -D /usr/local/var/postgres

entonces, ejecuté ese comando y obtuve:

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

Ahora, cuando miro mi Monitor de actividad, puedo ver 6 instancias de postgreso.

¿Cómo puedo solucionar esto?

Anuncio de servicio público: nunca eliminar postmaster.pid. De Verdad. Gran manera de obtener corrupción de datos.

Ya tenía instalado PostgreSQL y eliminó el directorio de datos sin detener el servidor en ejecución. Entonces, ahora tiene algunos procesos huérfanos del servidor PostgreSQL que administran archivos de datos que se han eliminado, por lo que ya no son accesibles en el sistema de archivos y se eliminarán por completo cuando se cierre el último identificador de archivo abierto. No puede usarlo pg_ctlpara apagar el servidor normalmente porque ha eliminado el clúster de datos, por lo que simplemente debe eliminar los procesos. Mata al administrador de correos (no lo uses kill -9, solo una matanza ordinaria lo hará) y el resto también se cerrará.

Entonces podrá iniciar un nuevo servidor en el datadir contra los initdbdatos recién actualizados .

Es muy probable que experimente conflictos en el camino a menos que desinstale la otra versión anterior de PostgreSQL.

En una palabra:

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

Anote el número en la primera línea, que es el pid del administrador de correo.

Verifique con pseso que el pid es el de un postmaster postgres.

Elimine el proceso de administrador de correo con el siguiente comando, reemplazando 'PID' con el número que anotó. Nuevamente, no use kill -9o kill -KILLsimplemente use un simple kill, es decir, unSIGTERM :

kill PID

Si el pid no es el de un administrador de correo de postgres, manualmente killcualquier postgresback-end que todavía se esté ejecutando, verifique que ya no se esté ejecutando y solo luego elimínelo postmaster.pid. (También debe verificar que postmaster.pidno esté en el almacenamiento compartido donde el servidor podría estar ejecutándose en alguna otra VM / host).

Otra posibilidad es que haya tenido un apagado forzado y el proceso de postgres haya muerto sin limpiar su archivo pid. Esto me sucede cuando la batería de mi computadora portátil se agota.

Esta solución no es para un sistema de producción, y realmente debería asegurarse de que el demonio postgres no se esté ejecutando , pero uso mi computadora portátil para la codificación y no me preocupa la necesidad de regenerar mis bases de datos.

Entonces, si otro proceso, o ninguno, se está ejecutando en ese puerto, simplemente elimine el archivo pid, por ejemplo

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

y los postgres pronto comenzarán bien.

Para saber si se está ejecutando otro proceso en ese puerto, puede hacer

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

Entonces corre

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

para ver si funcionó. Debería ver

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 al menos eso es lo que acabo de ver después de hacer lo anterior :-))

(Y realmente, ¿no debería Postgres ser lo suficientemente inteligente como para darse cuenta de que no hay un proceso con PID 933 y eliminar el archivo pid falso por sí solo?)

Intenté todo esto en vano después de actualizar a Yosemite rompió mis postgres (instalados a través de homebrew).

Luego me topé con esta publicación de blog: http://ruckus.tumblr.com/post/100355276496/yosemite-upgrade-breaks-homebrew-installed-postgres

Primero necesitaba crear los directorios faltantes que aparentemente fueron eliminados durante la actualización (¡gracias Apple!).

$ cd /usr/local/var/postgres

$ mkdir {pg_tblspc,pg_twophase,pg_stat_tmp}

Luego, simplemente vuelva a iniciar postgres usando la secuencia de inicio normal de homebrew:

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

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

Gracias Ruckus Notes por ayudarme a resolver mi problema. Espero que te ayude también.

INSTRUCCIONES DE REINICIAR DURO

Tuve este mismo problema después de un reinicio completo. Después de verificar el postmaster.pidpid del archivo, noté que no tenía ningún proceso en ejecución. No quería borrar el archivo .pid, en su lugar usé un pg-stopalias que había creado en mi .bash_profile. este alias solo se ejecuta

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

Para referencia

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

salida de registro después 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

elaborar cerveza

Pensé que también debería mencionar aquí que si ha instalado postgres con homebrew, debería brew servicesechar un vistazo. Así es como prefiero iniciar / detener mis bases de datos.

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

Recibí este error después de, creo, mi computadora se bloqueó. PostgreSQL ni siquiera pudo comenzar debido a este error, por lo que matar el proceso no era la solución. Simplemente hice una copia de seguridad y luego eliminé el postmaster.pidarchivo y luego el error se detuvo y PG pudo comenzar de nuevo.

A veces los humildes pg_ctl -w restartpueden hacer el truco :-)

Eliminar postmaster.pid es en realidad algo muy decente que hacer en cada arranque, a ciegas. Eso es lo que hace mi sistema. Debido a que acaba de arrancar, sabe que no se está ejecutando ningún proceso de Postgres, y si se está recuperando de un cierre no limpio, este archivo estará allí para evitar su recuperación.

Un mejor diseño para Postgres sería colocar el archivo postmaster.pid en el sistema de archivos / run, por lo que se garantiza que se eliminará en cada reinicio. Muchos otros servidores funcionan de esa manera.