Re: Potential G2-item cycles under serializable isolation
От | Andres Freund |
---|---|
Тема | Re: Potential G2-item cycles under serializable isolation |
Дата | |
Msg-id | 20200611195436.6y45fyddffazhr7r@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Potential G2-item cycles under serializable isolation (Kyle Kingsbury <aphyr@jepsen.io>) |
Список | pgsql-bugs |
Hi, On 2020-06-11 08:39:13 -0400, Kyle Kingsbury wrote: > On 6/11/20 1:40 AM, Thomas Munro wrote: > > What do you think about this documentation update? > > I think this is really helpful! You can go a little further if you like. > Right now, SSI vs serializable and SI vs RR are both described as > "differences in behavior", which kinda leaves it unclear as to how those > levels are related. If you want to follow Berenson, Adya, et al.'s broad > interpretation, I'd say something like > > "Snapshot isolation prevents some anomalies, like phantoms, which repeatable > read allows. It also allows some anomalies, like G2-item (write skew), which > repeatable read prevents." I think the percentage of readers that understand "G2-item" or even "write skew", but don't already know what snapshot isolation implies, is pretty close to zero. I like the idea of having a bit more detail, but I think it'd have to be worded differently to be beneficial. I'd also phrase it as "some definitions of repeatable read", but ... :). Intuitively, and that's not meant as an argument for anything, I find prohibiting write skew in something named "repeatable read" just plain odd. Leaving naming aside, I think there's good practical reasons for applications using read-committed, snapshot isolation, and serializable. It's not obvious to me that there are cases where the Berenson definition of RR is something that's desirable to use over RR/SI/S. I suspect what we really want, medium term, is some guidelines around what isolation levels are appropriate for which use-case. But that's a nontrivial thing to write, I think, and there's lot of room for disagreements... Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: