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