Разница в семантике повторяемого чтения в MySQL и PostgreSQL - PullRequest
0 голосов
/ 06 июня 2018

Я понимаю, что и в MySQL, и в PostgreSQL уровень изоляции REPEATABLE READ заставит чтения увидеть моментальный снимок в начале транзакции.Но в документации MySQL по адресу https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html следующее примечание упоминается с примером

Снимок состояния базы данных применяется к операторам SELECT внутри транзакции, а не обязательно к операторам DML.Если вы вставляете или изменяете некоторые строки, а затем фиксируете эту транзакцию, оператор DELETE или UPDATE, созданный из другой параллельной транзакции REPEATABLE READ, может повлиять на эти только что зафиксированные строки, даже если сеанс не может запросить их.Если транзакция обновляет или удаляет строки, зафиксированные другой транзакцией, эти изменения становятся видимыми для текущей транзакции.Например, вы можете столкнуться с ситуацией, подобной следующей:

SELECT COUNT(c1) FROM t1 WHERE c1 = 'xyz';
-- Returns 0: no rows match.
DELETE FROM t1 WHERE c1 = 'xyz';
-- Deletes several rows recently committed by other transaction.

SELECT COUNT(c2) FROM t1 WHERE c2 = 'abc';
-- Returns 0: no rows match.
UPDATE t1 SET c2 = 'cba' WHERE c2 = 'abc';
-- Affects 10 rows: another txn just committed 10 rows with 'abc' values.
SELECT COUNT(c2) FROM t1 WHERE c2 = 'cba';
-- Returns 10: this txn can now see the rows it just updated.

Применимы ли те же примеры к PostgreSQL или не позволят такое поведение?

1 Ответ

0 голосов
/ 06 июня 2018

Этого не может быть в PostgreSQL.

Если REPEATABLE READ транзакция A пытается изменить строку, которая была изменена параллельной транзакцией B после того, как A был сделан снимок, Aполучит «ошибку сериализации».

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...