On 1/9/11 5:27 PM, Robert Haas wrote: > I agree. I think we should assume that existing code which asks for > serializable behavior wants serializable behavior, not broken > serializable behavior. There certainly could be cases where the > opposite is true (the code wants, specifically, our traditional > definition of serializability rather than actual serializability) but > I bet there's not a whole lot of them, and changing such code to ask > for REPEATABLE READ probably isn't extremely difficult.
I'm going to disagree here. For a large, sprawling, legacy application changing SERIALIZABLE to REPEATABLE READ in every place in the code which might call it can be prohibitively difficult. Further, many such applications would be written with workarounds for broken serializable behavior, workarounds which would behave unpredictably after an upgrade. As such, I'd tend to say that like other major behavior changes, we ought to have a LEGACY_SERIALIZABLE GUC for a couple of versions, defaulting to "FALSE". Otherwise SSI becomes an anti-feature for some users and prevents them from upgrading. On the other hand, I'm not sure how many users ever use SERIALIZABLE mode. That would be the main counter-argument. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers