Неповторяемое чтение обнаруживает изменение прежней строки, фантомное — изменение состава результата. Снимок определяет, какие версии и строки видны повторному запросу.
Практический смысл
Почему это важно
Запрос «есть ли уже резерв по этому условию» проверяет видимые строки в определённый момент. Его пустой результат ещё не запрещает другому сеансу создать резерв. При выборе изоляции нужно отдельно защитить правило заказа и проверить, что происходит при параллельной вставке.
Доказательная часть
Что подтверждено
Фантомное чтение возникает, когда повторный запрос с тем же условием в одной транзакции получает другой набор подходящих строк после фиксации параллельной транзакции. Причиной бывает вставка, удаление или изменение значения, от которого зависит попадание строки в результат.
Граница применимости: Аномалия изоляции SQL; собственные изменения читающей транзакции исключены.
При неповторяемом чтении меняется ранее прочитанная строка. При фантомном — состав строк, удовлетворяющих условию поиска. Проверка только прежних идентификаторов не обнаруживает все новые строки, которые теперь подходят под условие.
Граница применимости: Различение неповторяемого и фантомного чтения в модели изоляции SQL.
Первый запрос заказов со статусом «к отгрузке» вернул две строки. Другой сеанс вставил третий такой заказ и зафиксировал его. Если повторный запрос первой транзакции вернул три строки, возникло фантомное чтение, даже если прежние две строки не менялись.
Граница применимости: Учебный пример одного условия поиска, одной читающей транзакции и одной параллельной вставки.
В PostgreSQL 18 уровень Repeatable Read не допускает фантомного чтения: повторные обычные запросы используют один снимок. Это сильнее минимальных требований стандарта SQL к уровню с таким названием, где фантомы разрешены.
Граница применимости: PostgreSQL 18; обычные SELECT без собственных изменений результата.
PostgreSQL 18 Repeatable Read исключает фантомное чтение, но всё ещё допускает аномалии сериализации. Стабильный набор видимых строк не доказывает, что совместные решения параллельных транзакций эквивалентны последовательному выполнению.
Граница применимости: Различие гарантий Repeatable Read и Serializable в PostgreSQL 18.
Пустой результат SELECT сам не обеспечивает уникальность будущей вставки. Если правило выражается уникальностью ключа, его закрепляют соответствующим ограничением базы. Для более сложного правила отдельно проверяют изоляцию всей операции и обработку конфликтов.
Граница применимости: PostgreSQL 18: проверка отсутствия без отдельной блокировки или иного механизма согласования; уникальность по ключу отличается от произвольного межстрочного правила.
Граница терминов
Не путать
Фантом виден при повторе одного запроса. Аномалию сериализации обнаруживают по совместному результату транзакций; она возможна и при неизменных снимках без фантомов.
Перед спецификацией
Что проверить
- Запишите точное условие поиска, включая статус, диапазон дат и границы сравнения.
- Повторите запрос в той же транзакции после фиксации параллельной вставки.
- Проверьте также удаление строки и изменение поля, по которому она попадает в результат.
- Разделите изменение прежних строк и появление новых подходящих строк.
- Для PostgreSQL сверяйте фактические гарантии режима, а не только название уровня SQL.
- Проверку отсутствия подкрепите ограничением уникальности, если именно оно выражает правило.
- Отдельно испытайте совместный результат двух операций: отсутствие фантомов не исключает аномалию сериализации.
Открытые основания
Первоисточники
PostgreSQL 18 Documentation: Transaction Isolation
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 13.2
Определяет isolation phenomena и фактическое поведение PostgreSQL levels, включая Serializable.
Открыть первоисточникPostgreSQL 18 Documentation: Constraints
PostgreSQL Global Development Group · документация PostgreSQL 18, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Проверить CHECK и NULL, NOT NULL, UNIQUE и границу проверок одной строки; пример заказа — редакторское применение этих правил.
Открыть первоисточникPostgreSQL 18 Documentation: Introduction to MVCC
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 13.1
Объясняет multiversion snapshots и границу между MVCC и explicit locking.
Открыть первоисточник