эттаPgSQLAnonymous,
у вас ус отклеился
у вас там таблички N непришейкобылехвост. [стюдент рука--лицо ]
и да -- в пж при сериалайзебл будет откат второй
1.
2.
ОШИБКА: не удалось сериализовать доступ из-за зависимостей чтения/записи между транзакциями
DETAIL: Reason code: Canceled on identification as a pivot, during write.
HINT: Транзакция может завершиться успешно при следующей попытке.
а при repeatable read -- количество во второй будет соответствовать снепшоту при старте, а не нормальному, при read commited текущему состоянию.
резюме -- те, кто не умеют писать серверную логику [полк их надысь пополнился випросом] -- хотят сериалазебла, чтобы
клиентская реализация чисто серверного функционала хоть как-то ползала.
кто умеет -- пишут инкрементальную, а не агрегатную логику на сервере, и требуют именно readcommited-а, а не маргинальных снапшотов и т.п.
все маргинальные уровни изоляции требуются только для развесистых агрегатов типа отчетов по плохо связанным наборам. -- чтобы синхронизировать снапшоты отдельных расчётов
клиентов много, пишущие их разной квалификации и т.д.
создание и управление "золотой записи" (как в МДМ) святой долг СУБД, но для этого СУБД должна себе представлять, что такое "золотая запись" и какие правила ее формирования
имеющегося набора всяких чахлых констрейнтов и т.д. инструментария не хватает для интерпретации данных со стороны СУБД
