RETURNING を使用した PostgreSQL UPSERT 操作から一貫した結果を保証するにはどうすればよいですか?

PostgreSQL UPSERT 操作と RETURNING 句: 競合の処理

PostgreSQL の INSERT ... ON CONFLICT は、挿入と更新を組み合わせた更新/挿入機能を提供します。 ただし、DO NOTHING 句とともに RETURNING を使用すると、同時シナリオで不完全な結果が生じる可能性があります。

同時実行性の問題 1: 返された行の欠落

INSERT ... ON CONFLICT が完了する前に別のトランザクションがターゲット行を変更すると、更新/挿入で競合が検出されず、RETURNING 出力で行が欠落する可能性があります。

解決策:

いくつかのアプローチによりこれを軽減できます。

• 行数の検証: 入力行数を RETURNING 数と比較します。 不一致は行が欠落していることを示しており、ステートメントの再実行が求められます。
• 強制上書き: 別の CTE (共通テーブル式) により、欠落している行を挿入できます。 この方法は効果的ではありますが、複数のトランザクションが重複することでデッドロックが発生する危険性があります。

同時実行性の問題 2: 行ロック

行ロックが必要なトランザクションの場合は、ON CONFLICT DO UPDATE を WHERE FALSE とともに使用します。これにより、行は変更されずにロックされます。 追加のロックを行うには、これを SELECT ... FOR UPDATE と組み合わせます。

堅牢性を高めるためのデータ型の処理とキャスト

既存のソリューションでは、すべての同時シナリオには不十分です。 より包括的なアプローチには以下が含まれます:

低同時実行性:

• INSERT と SELECT UNION を使用して CTE を使用して、挿入された行と選択された行を区別します。
• CTE を使用して入力データ型を定義し、ターゲット テーブル スキーマに合わせます。

高い同時実行性:

• 低同時実行アプローチを使用します。
• 必要に応じて、欠落している行を強制的に挿入するための CTE を組み込みます。
• 同時実行性を管理するために、INSERT ... ON CONFLICT CTE 内の関連する行をロックします。

デッドロックの回避:

一貫した挿入順序により、デッドロックの発生が最小限に抑えられます。

データ型管理:

• 既存のリレーションを活用して、入力データ型を自動的に決定します。
• 自動列マッピングでは列名を省略します。

以上がRETURNING を使用した PostgreSQL UPSERT 操作から一貫した結果を保証するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。