Merge pull request #6435 from EnterpriseDB/pgd/bug-fix

PGD bug fix

product_docs/docs/pgd/5/conflict-management/conflicts/02_types_of_conflict.mdx

@@ -34,7 +34,7 @@ You can effectively eliminate this type of conflict by using [global sequences](
 ### INSERT operations that violate UNIQUE or EXCLUDE constraints
 
 An `INSERT`/`INSERT` conflict can violate more than one `UNIQUE` constraint, one of which might be the `PRIMARY KEY`. 
-With the addition of `EXCLUDE` constraint support in PGD 5.6, an `INSERT`/`INSERT`conflict can also violate one or more `EXCLUDE` constraints.
+With the addition of `EXCLUDE` constraint support in PGD 5.6, an `INSERT`/`INSERT` conflict can also violate one or more `EXCLUDE` constraints.
 
 In either of the following cases, applying the replication change produces a `multiple_unique_conflicts` conflict. Both of these cases result in a conflict against more than one other row.
 
@@ -177,13 +177,13 @@ changes, make those changes using Eager Replication.
 
 ### UPDATE operations that violate UNIQUE or EXCLUDE constraints
 
-Like [INSERT operations that violate multiple UNIQUE/EXLUDE constraints](#insert-operations-that-violate-unique-or-exclude-constraints), when an incoming `UPDATE` violates more than one `UNIQUE`/`EXCLUDE index (including the `PRIMARY KEY`) or violates a single `EXCLUDE` index such that more than one row is in conflict, PGD raises a `multiple_unique_conflicts` conflict.
+Like [INSERT operations that violate multiple UNIQUE/EXCLUDE constraints](#insert-operations-that-violate-unique-or-exclude-constraints), when an incoming `UPDATE` violates more than one `UNIQUE`/`EXCLUDE` index (including the `PRIMARY KEY`) or violates a single `EXCLUDE` index such that more than one row is in conflict, PGD raises a `multiple_unique_conflicts` conflict.
 
 PGD supports deferred unique constraints. If a transaction can commit on the source, then it applies cleanly on target, unless it sees conflicts. However, you can't use a deferred primary key as a REPLICA IDENTITY, so the use cases are already limited by that and the warning about using multiple unique constraints.
 
 ### UPDATE/DELETE conflicts
 
-One node can update a row that another node deletes at ths same time. In this case an `UPDATE`/`DELETE` conflict can occur on replay.
+One node can update a row that another node deletes at the same time. In this case an `UPDATE`/`DELETE` conflict can occur on replay.
 
 If the deleted row is still detectable (the deleted row wasn't removed by `VACUUM`), the `update_recently_deleted` conflict is generated. By default, the `UPDATE` is skipped, but you can configure the resolution for this. See [Conflict resolution](04_conflict_resolution) for details.
 
@@ -261,7 +261,7 @@ PGD has problems with the latter case because PGD relies on the uniqueness of id
 
 Applications that insert, delete, and then later reuse the same unique identifiers can cause difficulties. This is known as the [ABA problem](https://en.wikipedia.org/wiki/ABA_problem). PGD has no way of knowing whether the rows are the current row, the last row, or much older rows.
 
-Unique identifier reuse is also a business problem, since it is prevents unique identification over time, which prevents auditing, traceability, and sensible data quality. Applications don't need to reuse unique identifiers.
+Unique identifier reuse is also a business problem, since it prevents unique identification over time, which prevents auditing, traceability, and sensible data quality. Applications don't need to reuse unique identifiers.
 
 Any identifier reuse that occurs in the time interval it takes for changes to pass across the system causes difficulties. Although that time might be short in normal operation, down nodes can extend that
 interval to hours or days.
@@ -281,7 +281,7 @@ In single-master Postgres, any `INSERT`/`UPDATE` that refers to a value in the r
 In multi-master PGD. there are no inter-node row-level locks. An `INSERT` on the referencing table doesn't wait behind a `DELETE` on the referenced table, so both actions can occur concurrently. Thus an `INSERT`/`UPDATE` on one node on the referencing table can use a value at the same time as a `DELETE`
 on the referenced table on another node. The result, then, is a value in the referencing table that's no longer present in the referenced table.
 
-In practice, this situation occurs if the `DELETE` operations occurs on referenced tables in separate transactions from `DELETE` operations on referencing tables, which isn't a common operation.
+In practice, this situation occurs if the `DELETE` operations occur on referenced tables in separate transactions from `DELETE` operations on referencing tables, which isn't a common operation.
 
 In a parent-child relationship such as Orders -> OrderItems, it isn't typical to do this. It's more likely to mark an OrderItem as canceled than to remove it completely. For reference/lookup data, it's unusual to completely remove entries at the same time as using those same values for new fact data.
 
@@ -399,4 +399,4 @@ as is normally the case with PGD AlwaysOn architecture.
 
 For the `insert_or_error` conflict resolution, the use of `REPLICA IDENTITY FULL` is still required.
 
-None of these problems associated with toasted columns affect tables with `REPLICA IDENTITY FULL`. This setting always logs a toasted value as part of the key since the whole row is considered to be part of the key. PGD can reconstruct the new row, filling the missing data from the key row. As a result, using `REPLICA IDENTITY FULL` can increase WAL size significantly.
+None of these problems associated with toasted columns affect tables with `REPLICA IDENTITY FULL`. This setting always logs a toasted value as part of the key since the whole row is considered to be part of the key. PGD can reconstruct the new row, filling the missing data from the key row. As a result, using `REPLICA IDENTITY FULL` can increase WAL size significantly.