Re: Serializable snapshot isolation patch
От | Jeff Davis |
---|---|
Тема | Re: Serializable snapshot isolation patch |
Дата | |
Msg-id | 1287679669.8516.618.camel@jdavis обсуждение исходный текст |
Ответ на | Re: Serializable snapshot isolation patch ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Serializable snapshot isolation patch
|
Список | pgsql-hackers |
On Thu, 2010-10-21 at 10:29 -0500, Kevin Grittner wrote: > Basically, when we already have a pivot, but no transaction has yet > committed, we wait to see if TN commits first. If so, we have a > problem; if not, we don't. There's probably some room for improving > performance by cancelling T0 or T1 instead of TN, at least some of > the time; but in this pass we are always cancelling the transaction > in whose process we detect the need to cancel something. Well, in this case we do clearly have a problem, because the result is not equal to the serial execution of the transactions in either order. So the question is: at what point is the logic wrong? It's either: 1. PreCommit_CheckForSerializationFailure() is missinga failure case. 2. The state prior to entering that function (which I believe I sufficiently described) is wrong. If it's (2), then what should the state look like, and how is the GiST code supposed to result in that state? I know some of these questions are answered in the relevant research, but I'd like to discuss this concrete example specifically. Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: