From d1f5f54ed4bccbca4f4df9fd593c35ef99a6974f Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan Date: Tue, 18 Jun 2024 16:12:45 +0100 Subject: [PATCH 1/2] Reworked conflicts Signed-off-by: Dj Walker-Morgan --- .../docs/pgd/5/consistency/conflicts.mdx | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/product_docs/docs/pgd/5/consistency/conflicts.mdx b/product_docs/docs/pgd/5/consistency/conflicts.mdx index 36c915ac514..b1c42e245ce 100644 --- a/product_docs/docs/pgd/5/consistency/conflicts.mdx +++ b/product_docs/docs/pgd/5/consistency/conflicts.mdx @@ -210,15 +210,17 @@ If the deleted row is still detectable (the deleted row wasn't removed by `VACUU The database can clean up the deleted row by the time the `UPDATE` is received in case the local node is lagging behind in replication. In this case, PGD can't differentiate between `UPDATE`/`DELETE` conflicts and [INSERT/UPDATE conflicts](#insertupdate-conflicts). It generates the `update_missing` conflict. -Another type of conflicting `DELETE` and `UPDATE` is a `DELETE` that comes after the row was updated locally. In this situation, the outcome depends on the type of conflict detection used. When using the -default, [origin conflict detection](#origin-conflict-detection), no conflict is detected, leading to the `DELETE` being applied and the row removed. If you enable [row version conflict detection](#row-version-conflict-detection), a `delete_recently_updated` conflict is generated. The default resolution for a `delete_recently_updated` conflict is to `skip` the deletion. However, you can configure the resolution or a conflict trigger can be configured to handle it. +Another type of conflicting `DELETE` and `UPDATE` is a `DELETE` that comes after the row was updated locally. In this situation, the outcome depends on the type of conflict detection used. + +When using the default, [origin conflict detection](#origin-conflict-detection), a `delete_recently_updated` conflict is generated. The default resolution for a `delete_recently_updated` conflict is to `skip` the deletion. However, you can configure the resolution or a conflict trigger can be configured to handle it. + +If you enable [row version conflict detection](#row-version-conflict-detection) no conflict is detected, leading to the `DELETE` being applied and the row removed. #### INSERT/UPDATE conflicts When using the default asynchronous mode of operation, a node might receive an `UPDATE` of a row before the original `INSERT` was received. This can happen only when three or more nodes are active (see [Conflicts with three or more nodes](#conflicts-with-three-or-more-nodes)). -When this happens, the `update_missing` conflict is generated. The default conflict resolver is `insert_or_skip`, though you can use `insert_or_error` or `skip` instead. Resolvers that do insert-or-action first try to `INSERT` a new row based on data from the `UPDATE` when possible (when the whole row was received). For reconstructing the row to be possible, the table either needs to have -`REPLICA IDENTITY FULL` or the row must not contain any toasted data. +When this happens, the `update_missing` conflict is generated. The default conflict resolver is `insert_or_skip`, though you can use `insert_or_error` or `skip` instead. Resolvers that do insert-or-action first try to `INSERT` a new row based on data from the `UPDATE` when possible (when the whole row was received). For reconstructing the row to be possible, the table either needs to have `REPLICA IDENTITY FULL` or the row must not contain any toasted data. See [TOAST support details](#toast-support-details) for more info about toasted data. @@ -511,9 +513,7 @@ Note that: PGD provides the option to use row versioning and make conflict detection independent of the nodes' system clock. -Row version conflict detection requires that you enable three things. If any of these steps aren't performed correctly then [origin conflict detection](#origin-conflict-detection) is used. - -- Enable `check_full_tuple` or the PGD node group. +Row version conflict detection requires that you enable two things. If any of these steps aren't performed correctly then [origin conflict detection](#origin-conflict-detection) is used. - Enable `REPLICA IDENTITY FULL` on all tables that use row version conflict detection. @@ -529,7 +529,7 @@ This approach resembles Lamport timestamps and fully prevents the ABA problem fo To determine the current conflict resolution strategy used for a specific table, refer to the column `conflict_detection` of the view `bdr.tables`. -### bdr.alter_table_conflict_detection +### `bdr.alter_table_conflict_detection` Allows the table owner to change how conflict detection works for a given table. From d1ffeee66de166cc469227853c2bb89905d97007 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan <126472455+djw-m@users.noreply.github.com> Date: Tue, 18 Jun 2024 17:48:01 +0100 Subject: [PATCH 2/2] Fixed as per Petr review --- product_docs/docs/pgd/5/consistency/conflicts.mdx | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/product_docs/docs/pgd/5/consistency/conflicts.mdx b/product_docs/docs/pgd/5/consistency/conflicts.mdx index b1c42e245ce..335ffdaf285 100644 --- a/product_docs/docs/pgd/5/consistency/conflicts.mdx +++ b/product_docs/docs/pgd/5/consistency/conflicts.mdx @@ -210,11 +210,7 @@ If the deleted row is still detectable (the deleted row wasn't removed by `VACUU The database can clean up the deleted row by the time the `UPDATE` is received in case the local node is lagging behind in replication. In this case, PGD can't differentiate between `UPDATE`/`DELETE` conflicts and [INSERT/UPDATE conflicts](#insertupdate-conflicts). It generates the `update_missing` conflict. -Another type of conflicting `DELETE` and `UPDATE` is a `DELETE` that comes after the row was updated locally. In this situation, the outcome depends on the type of conflict detection used. - -When using the default, [origin conflict detection](#origin-conflict-detection), a `delete_recently_updated` conflict is generated. The default resolution for a `delete_recently_updated` conflict is to `skip` the deletion. However, you can configure the resolution or a conflict trigger can be configured to handle it. - -If you enable [row version conflict detection](#row-version-conflict-detection) no conflict is detected, leading to the `DELETE` being applied and the row removed. +Another type of conflicting `DELETE` and `UPDATE` is a `DELETE` that comes after the row was updated locally. In this situation, A `delete_recently_updated` conflict is generated. The default resolution for a `delete_recently_updated` conflict is to `skip` the deletion. However, you can configure the resolution or a conflict trigger can be configured to handle it. #### INSERT/UPDATE conflicts