Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> Overall, you're missing the point: there are workarounds for all
> of these things now. However, they are *workarounds*, which means
> that they are awkward, expensive, and/or hard to administrate;
> having predicate locks would make things much easier.
Well, if some form of the SSI patch goes in most of your use cases
can be solved just by making the transactions serializable and
letting the chips fall where they may. That's the whole point of
it. I'll say it again: with true serializable transactions, if you
can show that your transaction will do the right thing if there are
no concurrent transactions, it will do the right thing in any mix of
serializable transactions or be rolled back with a serialization
failure. Full stop. No need to explicitly lock anything (with or
without NOWAIT), no need to SELECT FOR UPDATE/SHARE, no need to
"reserve" anything -- I consider all of those to be awkward
workarounds. You just systematically retry transactions which fail
with SQLSTATE '40001'. If your software isn't set up so that this
can be done once, in one place, you need to rethink your design.
I'm not at all clear how any form of predicate locking can help with
the "blackouts" example. Perhaps if you explained how you see that
working I might get it.
Oh, and if deadlocks are that broken, it's a bit scary that we have
let that go. Is it the problem that technically intractable?
-Kevin