postgresを再起動することがオプションである場合、それはおそらく問題を解決し、この回答の残りを読むことに時間を費やす必要がなくなります:-)
pg_stat_activityを確認してください ビュー、スキーマの変更をブロックしている他のトランザクションがある可能性があります。
select * from pg_stat_activity
where
wait_event_type is NULL and xact_start is not NULL order by xact_start;
（pg_stat_activityは、すべてのメジャーpgリリースで少し変更されています。古いバージョンではこれを試してください）：
select * from pg_stat_activity
where
not waiting and xact_start is not NULL order by xact_start;
表示される最初の行は、おそらく問題を引き起こしている行です。多くの場合、これは「トランザクションのアイドル」です。これはロックを保持する可能性が非常に高く、古いトランザクションの場合はパフォーマンスが低下する可能性があります。おそらく、プログラマーは「コミット」または「ロールバック」でトランザクションを終了することを確認し忘れたか、ネットワークの問題のために一部のデータベースセッションがスタックした可能性があります。
pid 1234でトランザクションを終了するには、select pg_cancel_backend(1234);を使用します 、それが失敗した場合は、select pg_terminate_backend(1234) 。シェルアクセスの場合、同等のコマンドはkill -INT 1234です。 およびkill 1234 。 （覚えておいてください、kill -9 1234 本当に悪い考えです。
ビューpg_locksもあります これはある程度の洞察を与えるかもしれませんが、そこから有用な情報を引き出すのはおそらくそれほど簡単ではないかもしれません。 grantedの場合 trueの場合、grantedすると、ロックが保持されます falseは、クエリがロックを待機していることを意味します。 pg_locksから有用な情報を抽出する方法に関するヒントを次に示します。
他のすべてが失敗した場合は、おそらく簡単な解決策に取り掛かり、そのデータベースサーバーを再起動します。