Does every conflict require aborting a transaction?

No. The mechanism and dependency pattern determine whether waiting, versioning, retry or another behavior is appropriate.

Is a repeated read required for a read - write dependency?

No. Formal dependency analysis can identify a relevant relationship even if the application never reads the value twice.

Can inserting a new row matter?

Yes. A new row can change the result of an earlier predicate query, such as a check that no matching reservation exists.

AI Glossary / Data engineering and architecture / Intermediate

Read - write conflict

Definition

A read - write conflict occurs when one transaction reads information that another transaction changes, creating an ordering dependency that matters to concurrent execution. In introductory discussions, the term is sometimes used for the nonrepeatable-read problem, where a transaction reads a value again and sees a committed change. More formal concurrency theory uses read - write conflicts more broadly, including dependencies that do not produce an immediately visible repeated-read difference.

What it means

Reading is not always a passive activity from the viewpoint of correctness. A transaction may use what it reads to decide whether an update is allowed. If another transaction changes that information, the combined outcome may depend on their ordering. A conflict therefore identifies a relationship to analyze, not necessarily a bug or a failed transaction. Database mechanisms may block, preserve an older version, detect a serialization problem or permit the interaction under the chosen isolation level.

How it works

The database's concurrency-control method governs which versions a reader sees and how writes interact with that read. Under a locking approach, conflicting access may cause waiting. Under multiversion methods, a reader can continue seeing an older version while a writer creates a newer one. Serializable implementations may track read - write dependencies to prevent unacceptable combinations. Query predicates matter as well as individual rows: inserting a row that would have changed an earlier query's result can create a relevant dependency.

Three practical examples

An order transaction reads stock availability while another transaction changes the available quantity.
A report repeats a query and observes a changed value under an isolation level that permits nonrepeatable reads.
An AI job scheduler checks whether a worker slot is available while a concurrent transaction changes the slot's assignment.

Think of it this way

Think of two people coordinating work from a shared noticeboard. One reads a notice and makes a plan while another changes it. Their actions may be compatible, or the plan may rely on information that no longer holds. The analogy is limited because databases define precise visibility and ordering rules; the solution is not merely to tell users to look more carefully at the board.

Worked example

Suppose transaction T1 reads a product's quantity as ten. Transaction T2 changes it to seven and commits. T1 then reads the quantity again. If its isolation behavior allows the second statement to see the new committed value, T1 observes seven: a nonrepeatable read. Under a stable snapshot, it may continue seeing ten instead. That avoids this visible change but does not establish that every decision T1 makes is serializable. The example separates one observable anomaly from the broader question of whether all concurrent transactions preserve business rules.

Illustrative case study

In a fictional project, Maple Orders investigates reports that change within one user operation. Engineers reproduce the sequence with two database sessions and confirm that each statement sees a new committed snapshot under their configuration. They decide which operations need a stable view and which need stronger coordination around updates. They also test retry handling where required. This case demonstrates matching behavior to a requirement, without declaring every read - write overlap erroneous or prescribing one isolation level for all workloads.

Common misconceptions and mistakes

A read - write conflict is not necessarily a dirty read: a dirty read involves another transaction's uncommitted data. It is also distinct from a write - write conflict, although a transaction pair can have several dependency types. Stable snapshots do not remove every serialization anomaly. A conflict recorded internally may be handled correctly without an application-visible error. Conversely, the absence of an error message does not prove that a weakly isolated application preserved its intended cross-row rules.

Business use

Teams should define which concurrent outcomes are acceptable before choosing locking or isolation strategies. Review the reads that justify important writes, including range and existence checks. Test interleavings deliberately rather than relying on single-user tests. For AI processing systems, coordination errors can cause duplicate ownership or inconsistent job transitions even when the model itself works correctly. Monitor contention and retries, but interpret them alongside correctness: preventing an unsafe commit may be the intended behavior of the database.

Check your understanding

A transaction always sees the same snapshot. Can you conclude that its concurrent updates are serializable?

Answer: No. A stable view prevents some anomalies, but dependencies between transactions can still produce a nonserializable outcome under some snapshot-based isolation arrangements.

Related terms

Write - write conflict
Snapshot isolation
Concurrency control
Nonrepeatable read
dirty read
serializability
predicate locking

Learn next

Trace a two-transaction schedule and label each read and write with the version it observes or creates. Compare a changing statement snapshot with a stable transaction snapshot. Then study how read - write dependencies can form a cycle, keeping that formal notion separate from a single repeated-read example.

Sources

Sources: PostgreSQL 18, “Transaction Isolation,” https://www.postgresql.org/docs/18/transaction-iso.html; PostgreSQL 18, “Data Consistency Checks at the Application Level,” https://www.postgresql.org/docs/18/applevel-consistency.html; PostgreSQL project wiki, “Serializable,” https://wiki.postgresql.org/wiki/Serializable. The isolation documentation was opened and read earlier in this writing session; additional project-source search excerpts were consulted. Full formal and editorial review remain pending. The entry distinguishes the narrow introductory use from broader read–write dependency terminology.

Previous: Read speech Next: Real-time AI