Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> 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.
Yeah, you're right. I misread that example -- newbie with the
PERIOD type.
> So the question is: at what point is the logic wrong? It's either:
> 1. PreCommit_CheckForSerializationFailure() is missing a failure
> case.
> 2. The state prior to entering that function (which I believe I
> sufficiently described) is wrong.
It's (2). For the reasons I described in my previous email. Even
though misread the specifics of your example, I was close enough to
see where the problem was accurately. :-/
> If it's (2), then what should the state look like, and how is the
> GiST code supposed to result in that state?
The second insert should create conflicts similar to what the first
did, but in the other direction -- simple write skew. How GiST is
supposed to catch this is the big question. My logic that a
conflicting insert will modify a page read by the other transaction
only holds until someone inserts a conflicting entry. That's why it
wasn't reliably failing until you had and example where both
transactions accessing the same leaf page.
In your example, session 1's insert creates the leaf entry and
propagates entries up to the root. When session 2 inserts, it
can just modify the leaf, so the conflict is missed. As I said, the
most obvious way to fix this is to look for conflicts while
descending to the leaf for an insert. I'm almost sure we can do
better than that, but I haven't finished thinking it through. A
rough idea might be that when we find a conflict on an insert, we
acquire additional predicate locks on everything between the lowest
point of conflict and the leaf; the rest of the logic would remain
as-is. I haven't finished mulling that over, but it seems likely to
work. If we did that, session 2 would detect the conflict on the
insert to the leaf, and all would be well.
-Kevin