テクノロジー · 実用ガイド

PostgreSQLで relation does not exist？search_path変更前に失敗セッションを特定

SQLSTATE 42P01 は、アプリと管理シェルが別DB・schema・sessionで名前を解決していることがあります。失敗接続で読み取り専用プローブを実行し、証明した分岐だけを直します。

執筆 Watch at Ease News · 2 分で読めます公開 2026/10/18 14:20 UTC

pgAdmin や psql で表が見えても、アプリは relation does not exist を返せます。失敗したセッションのサーバー、DB、role、search path、識別子を確認します。

表の再作成や全体 search_path 変更、広い権限付与から始めません。元の接続でエラーと SQLSTATE を保存し、読み取り専用フィンガープリントを取ります。

失敗セッションを正確に採取

同じpool、transaction、roleで database、server address/port、user、role、search_path、current_schemas(true)を記録します。

relation token、引用、schema、SQLSTATEをそのまま保存し、管理シェルでも同じ指紋を取得します。

未修飾名とschema修飾名をto_regclassで調べ、pg_classとpg_namespaceでrelkind、persistence、visibilityを確認します。

両方NULLなら、誤DB、未適用またはrollback migration、削除、別sessionのtemp表を調べます。

catalogの綴りとSQLを比較します。"Orders"は正確な引用が必要です。

修飾名が存在するのに失敗する場合、schema USAGE、table privilege、API公開設定を別々に確認します。

作成したmigration toolまたはtransactionで同じ指紋を取り、host、port、DB、role、schemaを比較します。

未commit CREATE、失敗migration、別tenant、temp表はsearch_path変更で直りません。

一つの安定物体はschema修飾名を使います。未修飾が必要ならroleまたはconnection初期化を確認してpoolを再接続します。

renameとgrantは協調して最小限に行い、対象確認前に表を再作成しません。新しいapp接続で元の文を再実行します。