Две сессии под PostgreSQL Read Committed, один счёт с балансом 15, и обе сессии выполняют один и тот же оператор.
UPDATE accounts
SET balance = balance - 10
WHERE id = 1 AND balance >= 10;Сессия A обновляет строку и ещё не зафиксировала транзакцию. Сессия B находит строку, видит, что её обновляют, и ждёт. A фиксирует. B не применяет своё изменение к той версии, которую нашла вначале. Она берёт обновлённую версию, заново вычисляет условие WHERE, видит баланс 5 и ничего не обновляет. Баланс не уходит в минус, а нулевое число строк у B сообщает вызывающему, что списания не было.
Документация описывает эту перепроверку для UPDATE, DELETE и SELECT FOR UPDATE и заодно говорит, где она перестаёт помогать. Она касается только целевой строки. Условие, которое читает другие строки через подзапрос или соединение, не перевычисляется по их новым версиям, так что такой оператор может действовать по смеси состояний. Пример из самой документации - DELETE, чей WHERE совпадает со значением, которое меняет параллельный UPDATE, и в итоге ничего не удаляется, хотя подходящая строка есть и до, и после.
Значит, условие на одну строку в WHERE под Read Committed держится. Если условие смотрит во вторую таблицу, тут уже нужна блокировка строки или более строгий уровень изоляции.
