Greg Stark wrote:
> The unsolved problems that have been raised are:
> [legion]
Yeah, that's why this is a two to four year project. And I would
point out that if there *wasn't* a performance hit in serializable
mode, none of the other isolation levels would exist. These less
rigorous modes exist precisely because people are often willing to
give up some data integrity guarantees, or solve them with more
labor-intensive techniques, to gain performance. I certainly
wouldn't consider removing any of the existing transaction isolation
levels or attempt to coerce anyone into using them against their will.
;-)
I am keeping track of the lists you're putting out there; they should
be quite useful in the optimization phase. I do intend to first get
a patch which is "correct" in the sense of never allowing non-
serializable behavior, but which contains some of the problems you
list (although destroying modularity is obviously off the table even
for that point), and then refine the granularity and performance to
try to get within bounds which are acceptable for our use, and
hopefully (eventually) the PostgreSQL community.
One of the things I'm currently working on is what would make a good
set of tests to run during development to track progress. I welcome
any particular use-cases you want to ensure are covered. If you
could provide a detailed description or (even better) a self-
contained test case for something you would like to ensure is
covered, that would be most welcome.
Thanks,
-Kevin