で使用Fedora 15していPostgreSQL 9.1.4ます。Fedoraは最近クラッシュしました：

PostgreSQLサーバーを起動する試み：

service postgresql-9.1 start

与える

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

ただし、システムの再起動後に初めてサーバーを起動すると、サーバーは正常に起動します。
しかし、使用しようとするとpsqlこのエラーが発生します：

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.5432ファイルはシステムのどこにも存在しません。Aはlocate .s.PGSQL.5432何も出力しません。

システムログにはこれがあります：

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.

あ

systemctl status postgresql-9.1.service

与える

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

私はfsyncのデフォルト設定を変更していなかったので、私は推測しています、それはに設定されていましたon。HDDを使用しています。HDDがクラッシュしました。

HDDクラッシュ

HDDのクラッシュにより、fsckGUIベースではなくプロンプトでマニュアルが実行されました。ガジリオンのiノードなどを修復します。その後、システムをCtrl+ Alt+ + で再起動しましたDelete。

PostgreSQLのログはこれを持っています：

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

更新

/var/lib/pgsqlディレクトリのファイルシステムレベルのコピーを取得してサーバーを起動しよう./pg_resetxlog -f /var/lib/pgsql/9.1/data/としてxlog -f /var/lib/pgsql/9.1/data/も、結果は次のようになります。

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

実際の答えは、PostgreSQLのログにあり/var/lib/pgsql/data/pg_logます。

ただし、アクションを実行する前に、データの価値がある場合は、修復を試みる前にデータベースのファイルシステムレベルのコピーを作成することが重要です。http://wiki.postgresql.org/wiki/Corruptionを参照してください。データディレクトリ全体をコピーする必要があります。Fedoraでは/var/lib/pgsql/dataデフォルトですが、それがインストールに適していることを確認してください。

投稿したログに基づいて、確かにある程度のデータベースが破損しています。データベースが存在するストレージ（ハードドライブまたはファイルシステム）が破損している可能性があります。今すぐコピーを作成し、別のハードドライブまたはシステムに配置します。

データディレクトリの完全なファイルシステムレベルのコピーを作成したら、pg_resetxlogを使用して破損したトランザクションログをクリアし、データベースを起動してください。起動しても、破損している可能性が高いです。pg_dump再実行しinitdbて、ダンプを新しいインスタンスに復元する必要があります。

それでも起動できない場合pg_resetxlogは、resetxlogの後に起動試行の更新ログを投稿してください。次のコマンドを使用して、スタンドアロンモードでPgを起動する必要がある場合があります。

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

それが機能する場合は、backend>プロンプトが表示され、最後の「postgres」を接続先のDBの名前に置き換えてから再試行します。あなたのことができるようになりSELECT、COPYなど、テーブルのデータ

それが機能しない場合、つまりスタンドアロンバックエンドを開始できない場合は、バックアップから復元する時期です。これを読んでいる誰かが同じ立場にある場合は、経験豊富なPostgreSQLコンサルタントに連絡して、データベースからデータを回復できるかどうかを確認してください。彼らの時間と専門知識を支払う準備をしてください。

ファイルシステムが破損している可能性があります

PostgreSQLインストールの損傷の重大度は、ファイルシステム全体がおそらく損傷していることを示しています。システム全体をバックアップから復元するか、再インストールすることを検討してください。

私はこのファイルシステムを信頼しfsckませんfsck。

ドライブのスマートテスト

また、smartmontoolsからSMARTハードドライブのチェックを実行することをお勧めしますsmartctl。それ/dev/hdaがそうだと仮定してsmartctl -d ata -a /dev/sda | less。失敗したヘルステスト、uncorrectable_sectors高い読み取りエラー率、2または3を超えるreallocated_sector_count、またはゼロ以外のcurrent_pending_sectorを探します。実行してsmartctl -d ata -t long /dev/sda、あなたのHDDに非破壊セルフテストを実行します。システムの通常の機能を妨げることはありません。推定時間が経過したら、smartctl -d ata /dev/sda再度実行し、自己テストログを調べて、それが経過したかどうかを確認します。

完璧とは言えないものがある場合は、ドライブを交換してください。

今後は、smartdドライブ障害の早期警告のために、このテストを自動化することを検討してください。

（この投稿の内容は、質問の更新によって廃止されました。同様の問題をトラブルシューティングしている場合は、この回答の編集履歴を確認してください）。