PostgreSQL サーバー接続エラーの解決方法: "/tmp/.s.PGSQL.5432" が見つからない

この記事では、PostgreSQL を使用中に発生する頻出のエラー「psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory」の原因と解決方法について詳しく解説します。MacOS（特にM1/M2チップ）環境での対処法を中心に説明します。

問題の概要

このエラーは、PostgreSQL サーバーへの接続に失敗したことを示しています。具体的には、クライアントがデフォルトのUnixソケット（/tmp/.s.PGSQL.5432）を見つけられず、サーバーが起動していないか、異なるポートでリッスンしている可能性があります。

主な原因

1. 不正なシャットダウン: サーバーが異常終了した場合に postmaster.pid ファイルが残る
2. ポートの競合: 異なるバージョンのPostgreSQLが異なるポートを使用している
3. ディスク容量不足: ストレージの空き容量不足による起動失敗
4. 設定ファイルの問題: postgresql.conf の設定ミス

解決方法

以下に、原因別の解決方法を記載します。

方法1: postmaster.pid ファイルの削除（最も一般的な解決策）

不正シャットダウンにより残ったロックファイルを削除します。

Intel Mac

rm /usr/local/var/postgres/postmaster.pid
brew services restart postgresql

M1/M2 Mac

rm /opt/homebrew/var/postgres/postmaster.pid
brew services restart postgresql

特定バージョン指定

rm /opt/homebrew/var/postgresql@15/postmaster.pid
brew services restart postgresql@15

TIP

ファイルの正確な場所を確認するには、以下のコマンドを実行してください：

find /usr -name "postmaster.pid" 2>/dev/null
find /opt -name "postmaster.pid" 2>/dev/null

方法2: PostgreSQLサービスの完全再起動

サービスを完全に停止してから再起動します。

brew services stop postgresql
# または brew services stop postgresql@15
rm /opt/homebrew/var/postgres/postmaster.pid
brew services start postgresql

方法3: プロセスの強制終了

バックグラウンドで残留しているPostgreSQLプロセスを強制終了します。

# PostgreSQLプロセスの確認
pgrep -l postgres

# すべてのPostgreSQLプロセスを終了
sudo pkill -u postgres

# もう一度確認してプロセスがなくなったことを確認
pgrep -l postgres

方法4: ログファイルの確認

エラーの詳細をログから確認します。

tail -f /usr/local/var/log/postgres.log
# または
tail -f /opt/homebrew/var/log/postgresql@15.log

ログに以下のようなエラーが表示される場合、方法1の解決策が有効です：

FATAL: lock file "postmaster.pid" already exists

方法5: データベースの明示的指定

データベース名を明示的に指定して接続を試みます。

psql -d postgres
# または
psql -d postgres -U $(whoami)

方法6: ディスク容量の確認

ストレージの空き容量不足が原因の場合があります。

df -H

ルートディレクトリの使用率が100%に近い場合、ファイルを整理して空き容量を確保してください。

方法7: PostgreSQLの再インストール

上記の方法で解決しない場合、再インストールを検討します。

brew uninstall --force postgresql
brew install postgresql
brew services start postgresql

予防策

将来同じ問題が発生することを防ぐための対策：

1. 正常なシャットダウン: PostgreSQLサービスを常に正しく停止する

   brew services stop postgresql

2. 自動クリーンアップスクリプト: 開発環境では起動時に残留PIDファイルを削除するスクリプトを追加

   # Ruby (Sinatra/Rails)の例
   if ENV['RACK_ENV'] == 'development'
     pid_file = '/opt/homebrew/var/postgresql@15/postmaster.pid'
     File.delete(pid_file) if File.exist?(pid_file)
   end

3. 定期的なメンテナンス: 古いログファイルや一時ファイルの定期的なクリーンアップ

トラブルシューティングのフローチャート

以下に問題解決のための判断フローを示します：

よくある質問

Q: すべて試しても解決しない場合はどうすればいいですか？
A: PostgreSQLのバージョンとアーキテクチャ（Intel/M1）が一致しているか確認してください。また、環境変数DB_HOSTが正しく設定されているか確認しましょう。

Q: 本番環境でも同じ方法を使っても大丈夫ですか？
A: 本番環境では、データのバックアップを取得した上で、より慎重な対応が必要です。可能であれば、ドキュメントや専門家の助言を参照してください。

Q: データが消える心配はありますか？
A: postmaster.pidファイルの削除だけであれば、データが消失するリスクはほとんどありません。ただし、再インストールする場合はバックアップを取得してください。

まとめ

PostgreSQLの接続エラーは、ほとんどの場合postmaster.pidファイルの残留が原因です。本記事で紹介した方法を順に試すことで、問題解決が期待できます。開発環境では予防策を講じることで、今後同じ問題に直面する機会を減らすことができます。

それでも解決しない場合は、PostgreSQLのバージョンや環境設定を見直し、必要に応じて完全な再インストールを検討してください。