From 080ef2dbc65fa13ede8dcd38b3e1abc3ef84cdb4 Mon Sep 17 00:00:00 2001 From: Dj Walker-Morgan <126472455+djw-m@users.noreply.github.com> Date: Thu, 24 Aug 2023 12:42:45 +0100 Subject: [PATCH] Update product_docs/docs/pgd/5/consistency/conflicts.mdx Co-authored-by: Lenz Grimmer --- product_docs/docs/pgd/5/consistency/conflicts.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/product_docs/docs/pgd/5/consistency/conflicts.mdx b/product_docs/docs/pgd/5/consistency/conflicts.mdx index 4dafa0ca3b3..feca5ee7a32 100644 --- 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.