Consistency · XB Field Notes

Vector clocks distinguish causal order from concurrency

Sat, 18 Sep 2027 00:00:00 +0000

A vector records progress for each tracked participant. Comparing these counters distinguishes causal order from concurrency; the application still decides how to reconcile concurrent values.

One timestamp is not enough

A scalar timestamp can impose an order, but that order alone cannot prove causality. With stable participant identities and the usual event-clock rules, each process increments its own component for a local event. Receiving a message merges components by maximum and then increments the receiver’s component. These rules record information flow. They do not measure elapsed time or establish a physical-time ordering between machines that exchanged no information.

Compare vectors to see causality

Compare every component, treating an absent participant as zero. A is strictly before B only when all A components are at most B and at least one is smaller. Reverse domination means after; identical components mean equal. Only when neither vector dominates the other are they concurrent. Because a causal order accumulates everywhere the two paths crossed, a vector captures the transitive and direct edges that a single scalar time forfeits. The moment a message passes from A to B, B’s vector reflects both B’s own progress and everything A had seen, which is how the model traces causality instead of guessing it.

Concurrent means someone decides

Concurrency does not select a winner or necessarily imply a business conflict. Independent field updates might merge; incompatible replacements might require retaining siblings or asking a user. A deterministic tie-breaker can deliberately discard one value, but that is an application policy, not causality discovered by the clock. Equality means equal represented context; only an additional event-identity contract makes it proof that two payloads are the same event.

When it breaks

Clock size grows with the identities tracked by the chosen scheme. In Dynamo, components identify coordinating storage nodes, not every client that ever touched a key. Ephemeral participant identities and counter reuse after restart need explicit handling: reusing an old identity with a reset counter can make genuinely new work look obsolete. Stable identity is part of the algorithm’s assumptions, not an incidental implementation detail.

Pruning a component can lose a real ancestor relationship. Compare ancestor [A:2, C:4] with descendant [A:3, B:2, C:5]. Remove C from the descendant and the remaining vector now appears concurrent with the ancestor. Missing-as-zero is meaningful for an unseen participant; it cannot restore deliberately discarded history. Dynamo explicitly notes reconciliation imprecision from truncation. Dotted version vectors use a different causal representation; they are not permission to delete arbitrary components safely.

Comparing only sums, maxima, or nearby wall-clock values also loses information. [A:2, B:1] and [A:1, B:2] have equal sums but are concurrent. Carry the read context into a subsequent write so the store knows which versions it supersedes. Omitting that context can create siblings depending on the store and current versions; it does not guarantee a new sibling on every write. Retention and reconciliation require the store’s actual protocol.

Concurrent histories need a policy. Source-based mechanism illustration. Model values and source-reported observations are not a new runtime test.

Check it quickly

Save this as check_vector_clocks.py and run python3 check_vector_clocks.py. This in-memory comparison model covers all four relations, a merge followed by a receive-event increment, and a pruning counterexample. It creates no network, store, or persistent participant identity.

def compare(a, b):
 """Compare causal contexts with absent participants interpreted as zero."""
 nodes = set(a) | set(b)
 le = all(a.get(n, 0) <= b.get(n, 0) for n in nodes)
 ge = all(a.get(n, 0) >= b.get(n, 0) for n in nodes)
 if le and ge:
 return "equal"
 if le:
 return "before"
 if ge:
 return "after"
 return "concurrent"


def merge(a, b):
 return {n: max(a.get(n, 0), b.get(n, 0)) for n in set(a) | set(b)}


def tick(clock, node):
 result = dict(clock)
 result[node] = result.get(node, 0) + 1
 return result


a = {"A": 1}
b = tick(a, "B")
assert compare(a, b) == "before" and compare(b, a) == "after"
assert compare(a, a) == "equal"
assert compare({"A": 1}, {"A": 1, "B": 0}) == "equal"
assert a == {"A": 1} # tick does not mutate the input
c, d = {"A": 2, "B": 1}, {"A": 1, "B": 2}
assert compare(c, d) == compare(d, c) == "concurrent"
assert sum(c.values()) == sum(d.values()) # equal sums do not mean equal history
m = merge(c, d)
assert m == {"A": 2, "B": 2}
assert compare(c, m) == compare(d, m) == "before"
received = tick(m, "B")
assert received == {"A": 2, "B": 3} and compare(m, received) == "before"

# Truncation loses a genuine ancestor relationship.
ancestor = {"A": 2, "C": 4}
descendant = {"A": 3, "B": 2, "C": 5}
pruned = {"A": 3, "B": 2}
assert compare(ancestor, descendant) == "before"
assert compare(ancestor, pruned) == "concurrent"
print("PASS: four relations, merge-then-tick, zero slots, and false concurrency after pruning")

All assertions pass on Python 3.12.14. The merged concurrent histories are [A:2, B:2]; recording B’s receive event produces [A:2, B:3]. The pruning test changes a genuine before relation into concurrent, demonstrating a concrete loss of information rather than merely observing a shorter vector.

The model assumes valid nonnegative counters and a shared identity scheme. It does not test crash recovery, membership churn, client/server context exchange, or dotted versions. Those are separate integration properties. Passing comparison arithmetic cannot prove that a distributed store increments, persists, or retires its metadata correctly.

Sources

Dynamo: Amazon’s highly available key-value store, reconciliation with version vectors and sibling retention, checked 2026-10-15.
Preguiça et al.: Dotted Version Vectors, causal histories with bounded server identities and explicit update dots, checked 2026-10-15.

Choose transaction isolation to preserve the invariant

Sun, 23 Aug 2026 00:00:00 +0000

Choose an isolation level from the invariant an operation must preserve. A stable snapshot is useful, but two transactions can each make a locally reasonable decision that becomes invalid when both commit. PostgreSQL Repeatable Read prevents changes to a transaction’s reading snapshot, yet permits some serialization anomalies. Serializable adds detection that rejects combinations of concurrent work inconsistent with any serial execution, requiring the application to handle retries.

Repeatable Read can preserve both snapshots while breaking a cross-row rule. The controlled Serializable ordering rejects B; a full retry reads one doctor and updates no row. The diagram does not add runtime evidence.

Separate a stable view from a valid decision

Consider two on-call doctors and a rule that at least one must remain available. Each doctor may leave only after observing more than one available doctor. Two Repeatable Read transactions can both observe two, then update different rows to leave. Neither overwrites the other’s row. Both can commit, leaving zero doctors even though each transaction used an internally stable snapshot.

This is write skew, not a lost update to one shared row. Row-level checks on each doctor’s boolean state do not express the global availability rule. Protecting only the row being changed also misses the relationship between the two decisions. A suitable serialization protocol must cover the invariant’s complete scope.

Database implementations matter. PostgreSQL maps Read Uncommitted to Read Committed, and its Repeatable Read prevents phantom reads even though the SQL standard allows that level to permit them. Those properties do not remove write skew. Isolation names should lead to the engine’s documented guarantees, rather than an assumption that every database implements them identically.

When it breaks

Treating Serializable as a mode that physically executes every transaction one at a time is misleading. PostgreSQL runs transactions concurrently and tracks dependencies; a transaction may fail during execution or commit with SQLSTATE 40001. The application must retry the complete decision using fresh reads, not resubmit a commit or reuse values computed from the rejected snapshot.

Serializable also cannot repair a transaction that would violate the business rule even when run alone. Every relevant write path must follow the intended contract. A separate unrestricted update can still remove the last doctor. Higher isolation is a concurrency guarantee, not an automatic implementation of missing application logic.

Check it quickly

Open two fresh psql -X -v ON_ERROR_STOP=1 sessions, A and B, in the same disposable PostgreSQL 18 database. Use the same role, normal autocommit outside explicit blocks, and an unused schema name. Follow the order exactly; the overlapping reads are what establish the competing decisions.

In A, create the initial roster.

CREATE SCHEMA isolation_demo;
CREATE TABLE isolation_demo.doctors (id integer PRIMARY KEY,on_call boolean NOT NULL);
INSERT INTO isolation_demo.doctors VALUES (1,true),(2,true);

In A, begin and read; then do the same in B. Both counts must be two.

BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;

BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;

Update doctor one in A, then doctor two in B. Each update also checks the availability rule within its own snapshot.

UPDATE isolation_demo.doctors SET on_call=false WHERE id=1
 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id;

UPDATE isolation_demo.doctors SET on_call=false WHERE id=2
 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id;

Commit A, then B. In A, inspect the broken invariant and reset the roster after both transactions finish.

COMMIT;

\set ON_ERROR_STOP off
COMMIT;
\echo commit_state :SQLSTATE
\set ON_ERROR_STOP on

SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;

UPDATE isolation_demo.doctors SET on_call=true;

Repeat the overlapping decisions with Serializable: begin A, begin B, update A, update B, commit A, then attempt B’s commit.

BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;

BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;

UPDATE isolation_demo.doctors SET on_call=false WHERE id=1
 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id;

UPDATE isolation_demo.doctors SET on_call=false WHERE id=2
 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id;

COMMIT;

\set ON_ERROR_STOP off
COMMIT;
\echo commit_state :SQLSTATE
\set ON_ERROR_STOP on

In A, check availability. In B, retry the entire decision with a new transaction. Finish by checking and cleaning up in A.

SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;

BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;
UPDATE isolation_demo.doctors SET on_call=false WHERE id=2
 AND (SELECT count(*) FROM isolation_demo.doctors WHERE on_call)>1 RETURNING id;
COMMIT;

SELECT count(*) AS available FROM isolation_demo.doctors WHERE on_call;
DROP SCHEMA isolation_demo CASCADE;

The retained PostgreSQL 18.6 report records successful Repeatable Read commits and availability became zero. With the controlled Serializable ordering, A committed and B’s commit reported 40001; one doctor remained. Error stopping is disabled only around the commit being observed so psql can print its SQLSTATE. A different error is not the expected serialization result.

B’s fresh retry observed one available doctor. Its conditional update returned no row, and it committed without removing that last doctor. The final count stayed one. This verifies both anomaly prevention and recomputation after rejection; merely proving that an error occurred would not establish the recovery behavior.

Account for the real cost

Dependency tracking and repeated attempts consume resources, while explicit locking can introduce waiting and coordination overhead. Neither approach is universally faster. Measure the actual transaction mix, keep transactions short, and bound retries by attempts and the request deadline. Choose the mechanism that preserves the invariant under all participating paths, then verify its contention behavior with representative work.

Sources

PostgreSQL 18: Transaction isolation, snapshot isolation and Serializable dependency checks, checked 2026-09-10.
PostgreSQL 18: Serialization failure handling, SQLSTATE classification and full-transaction retry, checked 2026-09-10.

Consistency · XB Field Notes

Vector clocks distinguish causal order from concurrency

One timestamp is not enough

Compare vectors to see causality

Concurrent means someone decides

When it breaks

Check it quickly

Further reading

Sources

Choose transaction isolation to preserve the invariant

Separate a stable view from a valid decision

When it breaks

Check it quickly

Account for the real cost

Sources