On Fri, Jan 10, 2014 at 11:28 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> Why does it deadlock with the btreelock patch? I don't see why it should. If
> you have two backends inserting a single tuple, and they conflict, one of
> them should succeed to insert, and the other one should update.
Are you sure that it doesn't make your patch deadlock too, with enough
pressure? I've made that mistake myself.
That test-case made my patch deadlock (in a detected fashion) when it
used buffer locks as a value locking prototype - I say as much right
there in the November mail you linked to. I think that's acceptable,
because it's non-sensible use of the feature (my point was only that
it shouldn't livelock). The test case is naively locking a row without
knowing ahead of time (or pro-actively checking) if the conflict is on
the first or second unique index. So before too long, you're updating
the "wrong" row (no existing lock is really held), based on the 'a'
column's projected value, when in actuality the conflict was on the
'b' column's projected value. Conditions are right for deadlock,
because two rows are locked, not one.
Although I have not yet properly considered your most recent revision,
I can't imagine why the same would not apply there, since the row
locking component is (probably) still identical. Granted, that
distinction between row locking and value locking is a bit fuzzy in
your approach, but if you happened to not insert any rows in any
previous iterations (i.e. there were no unfilled promise tuples), and
you happened to perform conflict handling first, it could still
happen, albeit with lower probability, no?
--
Peter Geoghegan