web-dev-qa-db-ja.com

PostgreSQLシリアル化エラーのデバッグ

PostgreSQL 9.4データベースをトランザクションレベルから移行しようとしていますREAD COMMITTEDからREPEATABLE READまたはSERIALIZABLE。どちらの場合でも、次の形式の新しいエラーセットが表示されます。

(for both)
ERROR:  could not serialize access due to concurrent update
(just for SERIALIZABLE)
ERROR:  could not serialize access due to read/write dependencies among transactions

SSIのwikiページ および the docs を読んだ後、これらのエラーの原因となる可能性のあるエラー状態、それらの処理方法、さらにはそれらを回避するためのベストプラクティスさえ完全に理解しました。

ただし、PostgreSQLが提供できるデバッグ出力、または実際にはデバッグ情報からデータの依存関係を特定する方法はありません。ロールバック時に追加のクエリを実行するか、ログ記録メカニズムを使用して、データベースからこの情報を取得する方法はありますか?

この情報があれば、アプリケーションレベルの変更(ロック、別のクエリなど)を実行でき、データの競合を解消して、過剰なロールバックを回避できます。

6
Dan

あればいいのですが、現時点ではそれほど多くはないと思います。複数のステートメントが含まれることが多く、原因が必ずしも現在実行中のステートメントであるとは限らないため、特にコミット時の失敗では、特に注意が必要です。追加の情報を収集すると、パフォーマンスとメモリの使用率が低下しますが、デバッグ時にオンにできる優れたオプションです。

あなたの最善の策は、ログレベルを大幅に増やし、log_line_prefix含む%m%p%c:%lおよび%v:%xこれで、ログからセッションとそのxactを特定して再構築するために必要なトランザクションとセッションの情報が得られました。

5
Craig Ringer