Josh Berkus <j...@agliodbs.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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
