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

Co-authored-by: Lenz Grimmer <[email protected]>
EnterpriseDB · Oct 12, 2023 · 080ef2d · 080ef2d
1 parent ae65601
commit 080ef2d
Showing 1 changed file with 1 addition and 1 deletion.
diff --git a/product_docs/docs/pgd/5/consistency/conflicts.mdx b/product_docs/docs/pgd/5/consistency/conflicts.mdx
@@ -212,7 +212,7 @@ The database can clean up the deleted row by the time the `UPDATE` is received i
 
 Another type of `UPDATE`/`DELETE` conflict is when a `DELETE` for a row comes after that row was updated locally. In this situation, the outcome depends on the type of conflict detection used and the replication identity in use. 
 
-When using the default, [origin conflict detection](#origin-conflict-detection) and only primary keys for replication, no conflict is detected, leading to the `DELETE` being applied and the row being removed. 
+When using [origin conflict detection](#origin-conflict-detection) (the default) and only primary keys for replication, no conflict is detected, leading to the `DELETE` being applied and the row being removed. 
 
 If `REPLICA IDENTITY FULL` is being used for replication, the conflict will be detected and a `delete_recently_updated` conflict is generated.