Description
In a multi-master setup where writes are partitioned by row (e.g., Node 1 handles Odd UserIDs, Node 2 handles Even UserIDs), a re-subscription of a failed node results in replication conflicts. Although the data is successfully synchronized, the replication metadata (origin_id and origin_timestamp) is not preserved on the newly synchronized node.
Enviroment
2 nodes with postgres 16.10 with spock 5.0.4
Steps to Reproduce
Setup: Two nodes (n1, n2) in a multi-master configuration.
Initial State:
-
n1 inserts rows with Odd UserIDs.
-
n2 inserts rows with Even UserIDs.
-
Replication is healthy; no conflicts occur as write sets are disjoint.
-
Disaster Scenario: Delete/Drop n1.
-
Recovery: Re-subscribe n1 from n2 using:
- synchronize_data = true
- synchronize_structure = true
-
Resume Operation:
- n2 attempts to update an Even UserID row.
- n1 attempts to update an Odd UserID row an.
Actual Behavior
n1 reports a conflict for the Even rows updated by n2. Upon inspection, the rows on n1 created during the synchronization process lack the original origin_id and origin_timestamp from n2. Consequently, n1 treats incoming updates from n2 as conflicting with "local" data rather than following standard replication precedence.
Expected Behavior
The synchronize_data process should preserve the origin_id and origin_timestamp for each row so that the node that originally authored the data can continue to update those rows without triggering a conflict on the resubscribed node.
Description
In a multi-master setup where writes are partitioned by row (e.g., Node 1 handles Odd UserIDs, Node 2 handles Even UserIDs), a re-subscription of a failed node results in replication conflicts. Although the data is successfully synchronized, the replication metadata (origin_id and origin_timestamp) is not preserved on the newly synchronized node.
Enviroment
2 nodes with postgres 16.10 with spock 5.0.4
Steps to Reproduce
Setup: Two nodes (n1, n2) in a multi-master configuration.
Initial State:
n1 inserts rows with Odd UserIDs.
n2 inserts rows with Even UserIDs.
Replication is healthy; no conflicts occur as write sets are disjoint.
Disaster Scenario: Delete/Drop n1.
Recovery: Re-subscribe n1 from n2 using:
Resume Operation:
Actual Behavior
n1 reports a conflict for the Even rows updated by n2. Upon inspection, the rows on n1 created during the synchronization process lack the original origin_id and origin_timestamp from n2. Consequently, n1 treats incoming updates from n2 as conflicting with "local" data rather than following standard replication precedence.
Expected Behavior
The synchronize_data process should preserve the origin_id and origin_timestamp for each row so that the node that originally authored the data can continue to update those rows without triggering a conflict on the resubscribed node.