私の webapp では、いくつかのクエリが 3 分実行されます (私は知っています、それは巨大です ...)。同時に、別のユーザーが同じテーブルからデータを更新しようとしました。実行中の選択の終了を更新クエリが待機しているようです。
PostgreSQL の標準的な操作方法ですか? 選択クエリの終了前に実行するための更新を強制する方法はありますか?
ありがとう。
私の webapp では、いくつかのクエリが 3 分実行されます (私は知っています、それは巨大です ...)。同時に、別のユーザーが同じテーブルからデータを更新しようとしました。実行中の選択の終了を更新クエリが待機しているようです。
PostgreSQL の標準的な操作方法ですか? 選択クエリの終了前に実行するための更新を強制する方法はありますか?
ありがとう。
MVCC を無効にすることはできないため、これは問題ではありません。MVCC は、行がディスクに格納される方法を参照し、ロー ロックを回避します。
PostgreSQL のロックがいつ、どのように必要になるかを理解しようとするときは、MVCC を理解する必要があります。通常、リーダーはリーダーまたはライターをブロックしません。また、ライターがリーダーをブロックすることはめったにありません。
通常、リーダーとライターは、ステートメントまたはトランザクションの存続期間を通じてかなり安定しているスナップショットを使用することで、相互のブロックを回避できます (正確な安定性はトランザクション レベルによって異なります)。
行のロックは引き続き可能ですが、明示的に要求する必要があります。 SELECT ... FOR UPDATE
選択した行をロックします。SELECT
したがって、最初に行うことは、ステートメントにfor update
述語があるかどうかを確認することです。
そうでない場合は、分離レベルを確認し、read committed
分離レベルで実行してみてください
さらに、pg_locks テーブルをチェックして、実際にロックされているものを確認します。