Conflict types v7

The types of conflicts can be summarized as follows:

  • Uniqueness conflict. A uniqueness conflict occurs when the same value is used for a primary key or unique column in an insert transaction on two or more primary nodes. This conflict is also referred to as an insert/insert conflict.
  • Update conflict. An update transaction modifies a column value in the same row on two or more primary nodes. For example, an employee address column is updated on primary node A, and another user updates the address column for the same employee on primary node B. The timestamps of when the transactions occur on each node might differ, but both transactions occur in a time interval during which synchronization hasn't yet occurred. Thus when synchronization does take place, both conflicting transactions are applied. This conflict is also referred to as an update/update conflict.
  • Delete conflict. The row corresponding to an update transaction on the source node isn't found on the target node as the row was already deleted on the target node. This case is referred to as an update/delete conflict. Conversely, if there's a delete transaction on the source node and an update transaction for the same row on the target node, this case is referred to as a delete/update conflict. The case when the row corresponding to a delete transaction on the source node isn't found on the target node as the row was already deleted on the target node is referred to as a delete/delete conflict.

The following table definition shows conflict resolution examples:

CREATE TABLE addrbook (
    id              SERIAL PRIMARY KEY,
    name            VARCHAR(20),
    address         VARCHAR(50)
);

The following table shows an example of a uniqueness conflict.

TimestampAction
t1Node A: INSERT INTO addrbook (name, address) VALUES ('A', 'ADDR A');

Node A: INSERT INTO addrbook (name, address) VALUES ('B', 'ADDR B');
Primary node A

id = 1, name = 'A', address = 'ADDR A'

id = 2, name = 'B', address = 'ADDR B'
Primary node B
t2Node B: INSERT INTO addrbook (name, address) VALUES ('C', 'ADDR C');

id = 1, name = 'A', address = 'ADDR A'

id = 2, name = 'B', address = 'ADDR B'
id = 1, name = 'C', address = 'ADDR C'

t3Synchronization pushes Node A changes to Node BRow change for INSERT tx id = 1 on Node A results in unique key conflict on Node B

id = 1, name = 'C', address = 'ADDR C'

id = 1, name = 'A', address = 'ADDR A'

The following table shows an example of an update conflict.

TimestampAction
`t0'
t1Node A: UPDATE addrbook SET address = 'ADDR B1' WHERE id = 2;id = 2, address = 'ADDR B1'id = 2, address = 'ADDR B'
t2Node B: UPDATE addrbook SET address = 'ADDR B2' WHERE id = 2; Synchronization pushes Node A changes to Node Bid = 2, address = 'ADDR B1'id = 2, address = 'ADDR B2'
t3Synchronization pushes Node A changes to Node BCurrent value of address on Node B not equal old value on Node A ('ADDR B2' <> 'ADDR B')

The following table shows an example of a delete conflict.

TimestampAction
t0Primary node A

id = 2, address = 'ADDR B'
Primary node B

id = 2, address = 'ADDR B'
t1Node A: UPDATE addrbook SET address = 'ADDR B1' WHERE id = 2;id = 2, address = 'ADDR B1'id = 2, address = 'ADDR B'
t2Node B: DELETE FROM addrbook WHERE id = 2;id = 2, address = 'ADDR B1'Row with id = 2 deleted
t3Synchronization pushes Node A changes to Node BThe row with id = 2 is already deleted on target Node B, hence update from Node A fails.