Simon Riggs <si...@2ndquadrant.com> wrote: > They ask comparative questions like "What is the risk of > upgrade?", "How much testing is required?" > I never met a customer yet that has an automated test suite > designed to stress the accuracy of results under concurrent > workloads I'll try to provide some information here to help you answer those questions. I hope it is helpful. The only behavioral difference an unchanged application could see (short of some as-yet-undiscovered bug) is that they could get more serialization failures when using serializable isolation level than they previously got, and that there could be a performance impact. It really does nothing except run exactly what serializable mode was before, while monitoring for conditions which are present when a race condition between transactions might cause odd results, and generate a serialization failure as needed to prevent that. It kind of "hangs off the side" of legacy behavior and watches things. No new blocking. No new deadlocks. No chance of results you didn't get before. It might also be worth reviewing this page: http://www.postgresql.org/docs/9.1/interactive/transaction-iso.html -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
