меняет запись в таблице, другая выбирает оттуда записи) могут вызвать ошибку сериализации?
Если одна только пишет, а другая только читает — по идее, нет.
Если есть партицыонирование и автосоздание партицый – возможно, что можэт.
Не, без этого всего
Так-то да, но замаскированный.
А вот в догонку - если две serializable транзакции меняют две разные строки, однако получаю ошибку сериализации [40001] ERROR: could not serialize access due to read/write dependencies among transactions Detail: Reason code: Canceled on identification as a pivot, during write. Можно пожалуйста пояснить почему нельзя так обновлять, хотя интуитивно строки разные и ничто не мешает им обновиться независимо
Методом проб кажется понял что это write skew, т.к. на repeatable read оно уже не повторяется
Это зависит ещё и от того, какие строки эти транзакцыи читали. Притом, дажэ не то, чтобы строки — а по каким условиям дажэ. И если например у одной получен вариант строки, которую вторая обновляет — а у второй получен вариант строки, которую обновляет первая — то сериализовать (выбрать такую последовательность, в которой одна транзакцыя идёт после другой) — не получится.
При апдейте в обоих транзакциях был where по уникальной колонке, для каждого запроса значение своё, не должны были строки пересечься (если я правильно понял) Кажется есть смысл глянуть как появляется write skew и что делатьс этим
Вопрос не только "при апдейте" — а вообще во всей транзакцыи.
Тогда не понял :( В транзакции вроде строк не читал никаких, в каждой транзакции чисто один апдейт
Покажыте текст апдэйта и определение таблиц – возможно, сможэм понять.
Обсуждают сегодня