J'utilise Fedora 15avec PostgreSQL 9.1.4. Fedora s'est écrasé récemment, après quoi:

Une tentative de démarrage du serveur PostgreSQL:

service postgresql-9.1 start

donne

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

Bien que le serveur démarre normalement lorsque je démarre le serveur pour la première fois après le redémarrage du système .
Mais, une tentative d'utilisation psqldonne cette erreur:

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.5432le fichier n'est présent nulle part sur le système. A locate .s.PGSQL.5432ne produit rien.

Le journal système a ceci:

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.

UNE

systemctl status postgresql-9.1.service

donne

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

Je n'avais pas changé le paramètre par défaut de fsync, donc je suppose qu'il était réglé sur on. Je suis sur un disque dur. Le disque dur s'est écrasé.

Crash du disque dur

Le crash du disque dur a entraîné l'exécution d'un manuel fsckà l'invite et non basé sur l'interface graphique. Avec elle réparant des inodes de gazillions etc. Après quoi j'ai redémarré le système avec un Ctrl+ Alt+ Delete.

Le journal de PostgreSQL a ceci:

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

Mise à jour

Essayer de démarrer le serveur après avoir pris une copie du /var/lib/pgsqlrépertoire au niveau du système de fichiers et exécuté ./pg_resetxlog -f /var/lib/pgsql/9.1/data/avec le résultat xlog -f /var/lib/pgsql/9.1/data/donne toujours:

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 vraie réponse sera dans les logs de PostgreSQL, dans /var/lib/pgsql/data/pg_log.

Cependant, avant d'entreprendre toute action: il est essentiel que vous preniez une copie au niveau du système de fichiers de votre base de données avant de tenter une réparation si l'une de vos données vous est précieuse . Voir http://wiki.postgresql.org/wiki/Corruption . Vous devez copier l'intégralité du répertoire de données. Sur Fedora, c'est /var/lib/pgsql/datapar défaut, mais vérifiez que c'est correct pour votre installation.

Sur la base des journaux que vous avez publiés, vous avez certainement un certain degré de corruption de la base de données. Le stockage sur lequel se trouve la base de données (le disque dur ou le système de fichiers) est très probablement endommagé. Prenez une copie MAINTENANT et placez-la sur un autre disque dur ou système .

Une fois que vous avez effectué une copie complète au niveau du système de fichiers de votre répertoire de données, essayez d'utiliser pg_resetxlog pour effacer les journaux de transactions endommagés et démarrer votre base de données. Même s'il démarre, il est très probable qu'il soit corrompu; vous devez pg_dumpensuite le réinstaller initdbet restaurer le vidage sur la nouvelle instance.

Si vous ne pouvez toujours pas le démarrer après un, pg_resetxlogpubliez un journal mis à jour de la tentative de démarrage après resetxlog. Il est possible que vous deviez démarrer Pg en mode autonome avec:

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

Si cela fonctionne, en vous donnant une backend>invite, essayez à nouveau après avoir remplacé le dernier "postgres" par le nom de la base de données à laquelle vous souhaitez vous connecter. Vous devriez pouvoir SELECT, les COPYdonnées des tables, etc.

Si cela ne fonctionne pas , c'est-à-dire que vous ne pouvez pas démarrer un backend autonome, alors il est probablement temps de restaurer à partir de sauvegardes - car vous êtes assez raisonnable pour les avoir. Si quelqu'un d'autre qui lit ceci est dans la même position, contactez un consultant PostgreSQL expérimenté pour voir s'il peut récupérer des données de votre base de données. Soyez prêt à payer pour leur temps et leur expertise.

Votre système de fichiers est probablement endommagé

La gravité des dommages causés à l'installation de PostgreSQL suggère que l'ensemble de votre système de fichiers est probablement endommagé. Vous pouvez envisager de restaurer l'intégralité du système à partir d'une sauvegarde ou de le réinstaller.

Je ne ferais pas confiance à ce système de fichiers, fsckou non fsck.

Testez SMART votre lecteur

Je vous recommande également d'exécuter une SMARTvérification sur votre disque dur avec smartctlde smartmontools; en supposant /dev/hdaque ce serait smartctl -d ata -a /dev/sda | less. Recherchez un test d'intégrité ayant échoué uncorrectable_sectors, un taux d'erreur de lecture élevé, un nombre de secteurs réalloués supérieur à 2 ou 3 ou un secteur de dépenses actuel non nul. Exécutez smartctl -d ata -t long /dev/sdapour exécuter un autotest non destructif sur votre disque dur; il n'interrompra pas le fonctionnement normal du système. Une fois le temps estimé écoulé, exécutez à smartctl -d ata /dev/sdanouveau et consultez le journal d'autotest pour voir s'il s'est écoulé.

Si quelque chose semble moins que parfait, remplacez le lecteur.

À l'avenir, envisagez d'automatiser ces tests via smartdpour une alerte précoce des pannes de disque.

(Le contenu de ce message a été obsolète par les mises à jour de la question. Si vous dépannez un problème similaire, consultez l'historique des modifications de cette réponse).