Sto usando Fedora 15con PostgreSQL 9.1.4. Fedora si è schiantato di recente dopo di che:

Un tentativo di avviare il server PostgreSQL:

service postgresql-9.1 start

dà

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

Tuttavia, il server si avvia normalmente quando avvio il server per la prima volta dopo il riavvio del sistema .
Tuttavia, un tentativo di utilizzo psqlgenera questo errore:

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.5432il file non è presente in nessun punto del sistema. A locate .s.PGSQL.5432non emette nulla.

Il registro di sistema ha questo:

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.

UN

systemctl status postgresql-9.1.service

dà

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

Non avevo modificato l'impostazione predefinita di fsync, quindi suppongo che fosse impostato su on. Sono su un HDD. L'HDD si è bloccato.

Crash dell'HDD

Il crash dell'HDD ha provocato l'esecuzione di un manuale fscksu un prompt e non basato sulla GUI. Con esso riparando gazillion inode ecc. Dopo di che ho riavviato il sistema con un Ctrl+ Alt+ Delete.

Il registro di PostgreSQL ha questo:

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

Aggiornare

Il tentativo di avviare il server dopo aver /var/lib/pgsqleseguito una copia della directory a livello di file system e l'esecuzione ./pg_resetxlog -f /var/lib/pgsql/9.1/data/con il risultato xlog -f /var/lib/pgsql/9.1/data/restituisce comunque:

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 vera risposta sarà nei log di PostgreSQL, in /var/lib/pgsql/data/pg_log.

Tuttavia, prima di intraprendere qualsiasi azione: è fondamentale eseguire una copia a livello di file system del database prima di tentare la riparazione se uno qualsiasi dei dati è prezioso per l'utente . Vedi http://wiki.postgresql.org/wiki/Corruption . È necessario copiare l'intera directory dei dati. Su Fedora è /var/lib/pgsql/datadi default, ma verifica che sia corretto per la tua installazione.

Sulla base dei registri che hai pubblicato hai sicuramente un certo grado di corruzione del database. La memoria su cui si trova il database (il disco rigido o il file system) è molto probabilmente danneggiata. Prendi una copia ADESSO e mettila su un altro disco rigido o sistema .

Solo dopo aver creato una copia completa a livello di file system della directory dei dati, provare a utilizzare pg_resetxlog per cancellare i registri delle transazioni danneggiati e avviare il database. Anche se inizia, è molto probabile che sia corrotto; dovresti pg_dumpquindi reinserirlo initdbe ripristinare il dump nella nuova istanza.

Se non riesci ancora ad avviarlo dopo aver pg_resetxlogpubblicato un registro aggiornato del tentativo di avvio dopo resetxlog. È possibile che tu debba avviare Pg in modalità stand-alone con:

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

Se funziona, dandoti un messaggio backend>, riprova dopo aver sostituito gli ultimi "postgres" con il nome del DB a cui vuoi connetterti. Dovresti essere in grado di SELECT, COPYdati da tabelle, ecc.

Se ciò non funziona, ovvero non è possibile avviare un back-end autonomo, è probabilmente il momento di eseguire il ripristino dai backup, poiché sei abbastanza ragionevole da averli. Se qualcun altro che sta leggendo questo messaggio si trova nella stessa posizione, contatta un consulente PostgreSQL esperto per vedere se è in grado di recuperare i dati dal tuo database. Preparati a pagare per il loro tempo e competenza.

Il tuo file system è probabilmente danneggiato

La gravità del danno all'installazione di PostgreSQL suggerisce che probabilmente l'intero file system è danneggiato. Si consiglia di ripristinare l'intero sistema da un backup o reinstallarlo.

Non mi fiderei di questo file system fscko no fsck.

SMART-test l'unità

Consiglio anche di eseguire un SMARTcontrollo sul disco rigido con smartctlda smartmontools; supponendo /dev/hdache sarebbe smartctl -d ata -a /dev/sda | less. Cerca un test di integrità non riuscito uncorrectable_sectors, un tasso di errore di lettura elevato, un reallocated_sector_count superiore a 2 o 3 o un current_pending_sector diverso da zero. Esegui smartctl -d ata -t long /dev/sdaper eseguire un autotest non distruttivo sul tuo HDD; non interromperà il normale funzionamento del sistema. Trascorso il tempo stimato, esegui di smartctl -d ata /dev/sdanuovo e osserva il registro del test automatico per vedere se è passato.

Se qualcosa sembra meno che perfetto, sostituire l'unità.

In futuro, prendere in considerazione la possibilità di automatizzare questo test tramite smartdun avviso tempestivo di guasti dell'unità.

(Il contenuto di questo post era obsoleto dagli aggiornamenti alla domanda. Se stai risolvendo un problema simile, guarda la cronologia delle modifiche di questa risposta).