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
