Greg Stark <stark(at)enterprisedb(dot)com> wrote:
> Just as carefully written SQL code can be written to avoid deadlocks
> I would expect to be able to look at SQL code and know it's safe
> from serialization failures, or at least know where they might
> occur.
This is the crux of our disagreement, I guess. I consider existing
techniques fine for situations where that's possible. But, could you
give me an estimate of how much time it would take you, up front and
ongoing, to do that review in our environment? About 8,700 queries
undergoing frequent modification, by 21 programmers, for enhancements
in our three-month release cycle. Plus various ad hoc queries. We
have one full-time person to run ad hoc data fixes and reports
requested by the legislature and various outside agencies, like
universities doing research.
The whole point of the serializable transaction isolation level is
that it is the solution where you *can't* look at all your SQL code
and know where it's safe or where conflicts might occur. If you can
do that, it's very likely that you don't need this feature. The
proposed implementation, unlike traditional blocking techniques, won't
affect you if you don't choose to use serializable transactions.
Some people might be picturing the kind of blocking inherent in
traditional techniques where, for example, we had to run our read-only
web application at Read Uncommitted to avoid deadlocks with the
updates from replication. I like this technique because I don't think
I'd have to do that.
-Kevin