Estoy usando Fedora 15con PostgreSQL 9.1.4. Fedora se estrelló recientemente después de lo cual:

Un intento de iniciar el servidor PostgreSQL:

service postgresql-9.1 start

da

Starting postgresql-9.1 (via systemctl):  Job failed. See system logs and 'systemctl status' for details.
                                                       [FAILED]

Aunque, el servidor se inicia normalmente cuando lo inicio por primera vez después de reiniciar el sistema .
Pero, un intento de usar psqlda este error:

psql: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

.s.PGSQL.5432El archivo no está presente en ninguna parte del sistema. A locate .s.PGSQL.5432no produce nada.

El registro del sistema tiene esto:

Aug 14 17:31:58 localhost systemd[1]: postgresql-9.1.service: control process exited, code=exited status=1
Aug 14 17:31:58 localhost systemd[1]: Unit postgresql-9.1.service entered failed state.

UNA

systemctl status postgresql-9.1.service

da

postgresql-9.1.service - SYSV: PostgreSQL database server.
          Loaded: loaded (/etc/rc.d/init.d/postgresql-9.1)
      Active: failed since Tue, 14 Aug 2012 17:31:58 +0530; 58s ago
     Process: 2811 ExecStop=/etc/rc.d/init.d/postgresql-9.1 stop (code=exited, status=1/FAILURE)
     Process: 12423 ExecStart=/etc/rc.d/init.d/postgresql-9.1 start (code=exited, status=1/FAILURE)
    Main PID: 2551 (code=exited, status=1/FAILURE)
      CGroup: name=systemd:/system/postgresql-9.1.service

No había cambiado la configuración predeterminada de fsync, así que supongo que se configuró en on. Estoy en un disco duro. El HDD se estrelló.

HDD crash

El bloqueo del HDD resultó en la ejecución de un manual fscken un indicador y no en una interfaz gráfica de usuario. Con él reparando millones de inodes, etc. Después de lo cual reinicié el sistema con un Ctrl+ Alt+ Delete.

El registro de PostgreSQL tiene esto:

LOG:  database system was interrupted; last known up at 2012-08-14 17:31:57 IST
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/41A4E58
LOG:  redo is not required
FATAL:  could not access status of transaction 1
DETAIL:  Could not open file "pg_multixact/offsets/0000": No such file or directory.
LOG:  startup process (PID 13016) exited with exit code 1
LOG:  aborting startup due to startup process failure

Actualizar

Intentar iniciar el servidor después de tomar una copia del /var/lib/pgsqldirectorio a nivel del sistema de archivos , y ejecutarlo ./pg_resetxlog -f /var/lib/pgsql/9.1/data/con el resultado xlog -f /var/lib/pgsql/9.1/data/aún produce:

LOG:  database system was interrupted; last known up at 2012-08-14 18:46:36 IST
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/6000078
LOG:  redo is not required
FATAL:  could not access status of transaction 1
DETAIL:  Could not open file "pg_multixact/offsets/0000": No such file or directory.
LOG:  startup process (PID 13766) exited with exit code 1
LOG:  aborting startup due to startup process failure

La respuesta real estará en los registros de PostgreSQL, en /var/lib/pgsql/data/pg_log.

Sin embargo, antes de tomar cualquier medida: es vital que tome una copia a nivel de sistema de archivos de su base de datos antes de intentar reparar si alguno de sus datos es valioso para usted . Ver http://wiki.postgresql.org/wiki/Corruption . Debe copiar todo el directorio de datos. En Fedora, eso es /var/lib/pgsql/datapredeterminado, pero verifique que sea correcto para su instalación.

Según los registros que ha publicado, ciertamente tiene cierto grado de corrupción de la base de datos. El almacenamiento en el que se encuentra la base de datos (el disco duro o el sistema de archivos) probablemente esté dañado. Tome una copia AHORA y colóquela en un disco duro o sistema diferente .

Solo una vez que haya realizado una copia completa del nivel de sistema de archivos de su directorio de datos, intente usar pg_resetxlog para borrar los registros de transacciones dañados e iniciar su base de datos. Incluso si comienza, es muy probable que sea corrupto; pg_dumpentonces debería volverlo initdba restaurar y restaurar el volcado a la instancia nueva.

Si aún no puede iniciarlo después de un, pg_resetxlogluego publique un registro actualizado del intento de inicio después de resetxlog. Es posible que deba iniciar Pg en modo independiente con:

sudo -u postgres postgres --single -D /var/lib/pgsql/data -P -f i postgres

Si eso funciona, dándole un backend>mensaje, intente nuevamente después de reemplazar los últimos "postgres" con el nombre de la base de datos a la que desea conectarse. Debería poder SELECT, COPYdatos de tablas, etc.

Si eso no funciona, es decir, no puede iniciar un backend independiente, entonces probablemente sea hora de restaurar desde las copias de seguridad, ya que es lo suficientemente sensible como para tenerlas. Si alguien más que lee esto está en la misma posición, comuníquese con un consultor experimentado de PostgreSQL para ver si pueden recuperar datos de su base de datos. Esté preparado para pagar por su tiempo y experiencia.

Su sistema de archivos probablemente esté dañado

La gravedad del daño en la instalación de PostgreSQL sugiere que todo el sistema de archivos probablemente esté dañado. Es posible que desee considerar restaurar todo el sistema desde una copia de seguridad o reinstalarlo.

No confiaría en este sistema de archivos, fscko no fsck.

INTELIGENTE-prueba tu disco

También le recomiendo que ejecute una SMARTcomprobación en su disco duro con smartctlsmartmontools; suponiendo /dev/hdaque sea así smartctl -d ata -a /dev/sda | less. Busque una prueba de estado fallida uncorrectable_sectors, una alta tasa de error de lectura, un recuento_sector_reasignado de más de 2 o 3, o un sector_pending_pending no nulo. Ejecute smartctl -d ata -t long /dev/sdapara ejecutar una autocomprobación no destructiva en su HDD; No interrumpirá el funcionamiento normal del sistema. Cuando haya transcurrido el tiempo estimado, smartctl -d ata /dev/sdavuelva a ejecutarlo y mire el registro de autocomprobación para ver si pasó.

Si algo parece menos que perfecto, reemplace la unidad.

En el futuro, considere automatizar esta prueba a través smartdde la alerta temprana de fallas en la unidad.

(El contenido de esta publicación quedó obsoleto debido a las actualizaciones de la pregunta. Si está solucionando un problema similar, consulte el historial de edición de esta respuesta).