In concurrency control, the phantom problem may occur when:

Concept

A phantom (phantom read) is a concurrency anomaly defined at the level of a predicate / range query: a transaction runs a query that selects all rows matching some condition, and on re-running that same query within the transaction it sees a different set of rows because another transaction committed in between. The defining cause is that new rows matching the predicate become part of the result set.

Application

1. Transaction T1 runs SELECT * FROM employees WHERE salary > 50000 and reads N rows.

2. Transaction T2 inserts a new employee with salary 60000 and commits.

3. T1 re-runs the identical query and now reads N+1 rows. The extra row that appeared is the phantom — a row that satisfies the predicate but was not visible in the first read.

Because the anomaly is created by a newly appearing row, the situation that produces a phantom is when matching rows are added — i.e. when records are inserted.

Contrast (why the other situations are different)

• Deleting rows: a row that was read earlier disappears on re-read. This is a non-repeatable read — it concerns rows already in the result set, not new rows appearing. (This is the point that is commonly confused: a delete makes a row vanish; a phantom is a row appearing.)

• Modifying rows: the values of an already-read row change on re-read — also a non-repeatable read, about values of existing rows, not membership of the result set.

• Indexing rows: changing an index alters access paths only; it does not change which committed rows satisfy a predicate, so it does not create phantoms.

Cross-check / prevention

• Phantoms are eliminated by the Serializable isolation level.

• Mechanism: predicate / index-range locks block insertions into the scanned range until the reading transaction completes, so no new matching row can appear mid-transaction.

Result: the phantom problem may occur when records are inserted.