Я поэкспериментировал с сериализуемым режимом Postgres и обнаружил некоторый порядок коммитов, который не может выполнить транзакцию, но не провалит транзакцию в случае другого порядка фиксации.
Для приведенного ниже кода я запускаю из каждой транзакции одновременно, но выполняю операции с каждой транзакцией пошагово, поэтому я запускаю tx 1 и выполняю все ее операции, затем tx 2 и все операции, затем tx 3 Но после каждой преемственности я еще не совершаю это. После завершения всех операций на всех tx я начинаю коммит.
Табличные объявления:
drop table if exists si_test;
create table si_test (name text unique, num integer);
insert into si_test values('a',10);
insert into si_test values('b',20);
insert into si_test values('c',30);
Транзакции:
T1: begin transaction isolation level serializable;
T1: update si_test set num=45 where name='a';
T2: begin transaction isolation level serializable;
T2: select * from si_test where name='a'; -- -> this shows value 10
T2: update si_test set num=47 where name='b';
T3: begin transaction isolation level serializable;
T3: select * from si_test where name='b'; -- -> this shows value 20
И это мой порядок и результат коммита:
T1 -> T3 -> T2 : T2 serialization error
T1 -> T2 -> T3 : T2 serialization error
T2 -> T1 -> T3 : all committed
T2 -> T3 -> T1 : all committed
T3 -> T1 -> T2 : all committed
T3 -> T2 -> T1 : all committed
Из этих запросов я могу сказать, что существует сериализуемое расписание T3 -> T2 -> T1. Я прочитал в postgres SSI docs, что они проверяют наличие 2 «опасных структур / rw-зависимостей», чтобы сделать вывод, не нарушат ли некоторые параллельные транзакции сериализуемый график, что в моих тестах не должно быть.
Я проверил EXPLAIN ANALYZE, и он показывает, что мой экземпляр использует сканирование индекса для выполнения условия where
Мой вопрос: может ли кто-нибудь объяснить, что на самом деле происходит? Где улов в моем тесте?
Примечания: Тестовый запуск на Postgres 11.2 в Windows 10 Pro
Примечания 2: Эти 3 TX работают на 3 разных соединениях одновременно