Невідповідність читання, що повторюється


10

http://www.postgresql.org/docs/9.2/static/transaction-iso.html

Режим повторного читання забезпечує сувору гарантію того, що кожна транзакція бачить повністю стабільний вигляд бази даних. Однак ця думка не обов'язково завжди буде відповідати деякому послідовному (по черзі) виконанню паралельних транзакцій одного рівня. Наприклад, навіть транзакція, що займається лише читанням на цьому рівні, може побачити оновлений контрольний запис, який показує, що партія завершена, але не бачить один із записів деталей, який логічно є частиною пакету, оскільки він читав попередню редакцію контрольної записи . Спроби застосувати бізнес-правила за допомогою транзакцій, що виконуються на цьому рівні ізоляції, швидше за все, не спрацюють без ретельного використання явних блокувань для блокування суперечливих транзакцій.

Хіба це не фантомний зчитування, що неможливо в режимі повторного читання?

Документація говорить про те, що запит у транзакції з повторним читанням бачить знімок з моменту початку транзакції, то як можна було б запиту прочитати суперечливі дані?

Відповіді:


5

Ось моє читання цього розділу. Я визнаю, це заплутано.

Припустимо, у мене дві таблиці:

CREATE TABLE batch (
   id serial not null unique,
   control_code text primary key,
   date_posted date not null default now()
);

CREATE TABLE details (
   batch_id int not null references batch(id),
   description text,
   primary key(batch_id, description)
);

Тепер, припустимо, ми вставляємо записи партії та реквізитів у різні транзакції. Сесія 1 вставляє партію і починає вставляти деталі, але перед її завершенням починається сеанс 2. Сесія 2 отримує інформацію про заголовки партії, але не чекає на виконання деталей, щоб повідомити користувача про відсутність записів. Тепер, якщо ваша партія та деталі повністю знаходяться в одній транзакції, це ніколи не буде проблемою.

це буде відрізнятися від серіалізаційного, коли ви очікували б зачекати, коли попередня вставка завершиться, і здійснити її, або відкату, перш ніж визначити, повідомляти користувача про відсутність рядків.


3

У Вікі PostgreSQL є документ, який показує деякі проблеми, які можуть виникнути з певними комбінаціями транзакцій на рівні ізоляції транзакцій REPEATABLE READ, і як їх уникнути на рівні ізоляції транзакцій SERIALIZABLE, починаючи з PostgreSQL версії 9.1.

Він також включає приклад того, як можна було б здійснити транзакцію READ-ONLY для READEATABLE READ-ONLY для читання непослідовних даних.


@dezso Вас може зацікавити це
907th

1

Фантомні читання (не забудьте плутати це з повторюваними читаннями) можливі на рівні ізоляції "Повторне читання" ... в принципі. Але поведінка Postgresql де-факто, коли ви вибираєте "Повторне читання", сильніше стандартного (майже "серіалізаційна" ізоляція), так що фактично у вас не буде фантомного читання. Документи :

Коли ви вибираєте рівень Read Uncommitted, ви дійсно отримуєте прихильність читання, і фантомні читання неможливі в реалізації PostgreSQL Repeatable Read , тому фактичний рівень ізоляції може бути суворішим, ніж вибраний вами.

Тепер, що з цим застереженням: "цей погляд не обов'язково завжди буде відповідати деякому послідовному (по черзі) виконанню паралельних транзакцій одного рівня"? Я думаю (я не впевнений) це означає, що це означає, що знімок "ззовні" (зафіксований на початку транзакції) може врешті-решт включати рядки з інших транзакцій, але не включати деякі інші рядки з тієї самої транзакції.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.