Merge pull request #5778 from EnterpriseDB/DOCS-670--redux-feedback-o…

…n-pgd-3-7-conflicts-docs-g

Docs-670-redux - corrections post feedback

product_docs/docs/pgd/5/consistency/conflicts.mdx

@@ -210,15 +210,13 @@ 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, 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
 
 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 +509,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 +525,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.