Conflict functions ================== bdr.alter_table_conflict_detection ---------------------------------- テーブルの所有者は、特定のテーブルの競合検出がどのように動作するかを変更できます。 概要 ^^^^ .. code:: sql bdr.alter_table_conflict_detection(relation regclass, method text, column_name name DEFAULT NULL) パラメーター ^^^^^^^^^^^^ - ``relation`` — 新しい競合検出方法を設定するリレーションの名前。 - ``method`` — 使用する競合検出方法。 - ``column_name`` — 列検出データの保存に使用する列。これはスキップできます。その場合、列名は競合検出方法に基づいて選択されます。 ``row_origin`` メソッドは、メタデータストレージに追加の列を必要としません。 競合検出として認識されている方法は次のとおりです。 - ``row_origin`` — タプルに加えられた以前の変更のオリジン :ref:`オリジンの競合検出 <オリジンの競合検出>` を参照してください。これは、テーブルに追加の列を必要としないサポートされている唯一の方法です。 - ``row_version`` — 行バージョン列 :ref:`行バージョンの競合検出 <行バージョンの競合検出>` を参照してください。 - ``column_commit_timestamp`` — 列ごとのコミットタイムスタンプ :ref:`CLCD ` で説明。 - ``column_modify_timestamp`` — 列ごとの変更タイムスタンプ :ref:`CLCD ` で説明しています。 注 ^^ ``column_commit_timestamp`` と\ ``column_modify_timestamp`` の競合検出方法の違いの詳細については、 :ref:`Timestamps in column-level conflict resolution ` を参照してください。 このファンクションは、 ``DDL`` ステートメントと同じレプリケーションメカニズムを使用します。これは、レプリケーションが :ref:`ddl filters ` 構成の影響を受けることを意味します。 ファンクションは、列レベルの競合解決が有効になっているリレーションで\ ``DML`` グローバルロックを取得します。 このファンクションはトランザクションです。トランザクションの\ ``ROLLBACK`` を使用してエフェクトをロールバックできます。変更は現在のトランザクションに可視されます。 ``bdr.backwards_compatibility`` が30618以下に設定されていない限り、 ``relation`` の所有者のみが\ ``bdr.alter_table_conflict_detection`` ファンクションを実行できます。 .. Warning:: 追加の列を使用してメタデータを保存する方法から競合検出方法を変更すると、その列がドロップされます。 .. Warning:: このファンクションは、`bdr.camo_enable_client_warnings` で警告が無効になっていない限り、 CAMOを無効にし、警告を発します。 bdr.alter_node_set_conflict_resolver ------------------------------------ この機能は、特定のノードでの競合解決の動作を設定します。 .. _概要-1: 概要 ^^^^ .. code:: sql bdr.alter_node_set_conflict_resolver(node_name text, conflict_type text, conflict_resolver text) .. _パラメーター-1: パラメーター ^^^^^^^^^^^^ - ``node_name`` — 変更されるノードの名前。 - ``conflict_type`` — 設定を適用する競合タイプ :ref:`競合タイプのリスト <競合タイプのリスト>` を参照してください。 - ``conflict_resolver`` — 指定された競合タイプに使用するリゾルバー :ref:`競合リゾルバーのリスト <競合リゾルバーのリスト>` を参照してください。 .. _注-1: 注 ^^ 現在、ローカルノードのみを変更できます。ファンクション呼び出しはレプリケートされません。複数のノードの設定を変更する場合は、各ノードでファンクションを実行する必要があります。 このファンクションによる構成変更は、 ``bdr.create_node_group`` または\ ``bdr.alter_node_group`` で指定された競合解決のデフォルト動作をオーバーライドします。 このファンクションはトランザクションです。変更はロールバックできます。それらは現在のトランザクションに表示されます。 bdr.alter_node_set_log_config ----------------------------- ノードの競合ログ構成を設定します。 .. _概要-2: 概要 ^^^^ .. code:: sql bdr.alter_node_set_log_config(node_name text, log_to_file bool DEFAULT true, log_to_table bool DEFAULT true, conflict_type text[] DEFAULT NULL, conflict_resolution text[] DEFAULT NULL) .. _パラメーター-2: パラメーター ^^^^^^^^^^^^ - ``node_name`` — 変更されるノードの名前。 - ``log_to_file`` — ノードログファイルに記録するかどうか。 - ``log_to_table`` — ``bdr.conflict_history`` テーブルにログを記録するかどうか。 - ``conflict_type`` — ログに記録する競合タイプ。 NULLデフォルトはすべてを意味します。 - ``conflict_resolution`` — ログへの競合の解決。 NULLデフォルトはすべてを意味します。 .. _注-2: 注 ^^ ローカルノードのみを変更できます。ファンクション呼び出しはレプリケートされません。複数のノードの設定を変更する場合は、各ノードでファンクションを実行する必要があります。 このファンクションはトランザクションです。変更はロールバックできます。それらは現在のトランザクションに表示されます。 競合ログ構成のリスト ^^^^^^^^^^^^^^^^^^^^ ``bdr.node_log_config`` ビューには、すべてのロギング構成が表示されます。ここには、ロギング構成の名前、ログの場所、およびログに記録される競合のタイプと解決がリストされています。 競合のテーブルへのロギング ^^^^^^^^^^^^^^^^^^^^^^^^^^ ``log_to_table`` がtrueに設定されている場合、競合はテーブルにログに記録されます。競合ログのターゲットテーブルは\ ``bdr.conflict_history`` です。 このテーブルは列\ ``local_time`` でレンジパーティション化されています。テーブルはオートパーティションで管理されています。デフォルトでは、新しいパーティションは毎日作成され、過去1か月の競合が維持されます。その後、古いパーティションは削除されます。自動パーティションは、事前に7〜14のパーティションを作成します。 bdr_superuserはこれらのデフォルトを変更できます。 PGDによって管理されるすべてのテーブルで生成された競合はこのテーブルに記録されるため、正当なユーザーのみが競合したデータを読み取ることができるようにすることが重要です。 PGDは、 ``bdr.conflict_history`` テーブルでROW LEVEL SECURITYポリシーを定義することによりこれを行います。テーブルの所有者のみが、各テーブルの競合を読み取ることができます。基になるテーブルにRLSポリシーが定義、有効化、および適用されている場合、所有者でも競合を読み取ることはできません。 FORCEオプションで作成されたRLSポリシーは、テーブルの所有者にも適用されます。その場合、基になるテーブルの一部またはすべての行は、所有者でも読み取ることができない場合があります。したがって、PGDは、競合ログテーブルにより厳密なポリシーも適用します。 事前定義されたロール `bdr_read_all_conflicts `_ は、 bdr_superuserロールを付与せずに、\ ``bdr.conflict_history`` テーブルに記録された競合の詳細をすべて表示する必要があるユーザーに付与できます。 デフォルトのロール bdr_read_all_statsは、 ``bdr.conflict_history_summary`` というカタログビューにアクセスします。このビューにはユーザーデータが含まれないため、ログに記録された競合を監視できます。