On Sun, Jan 9, 2011 at 7:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: >> If the SSI patch were to be accepted as is, REPEATABLE READ would >> continue to provide the exact same snapshot isolation behavior which >> both it and SERIALIZABLE do through 9.0, and SERIALIZABLE would >> always use SSI on top of the snapshot isolation to prevent >> serialization anomalies. In his review, Jeff argued for a >> compatibility GUC which could be changed to provide legacy behavior >> for SERIALIZABLE transactions -- if set, SERIALIZABLE would fall back >> to working the same as REPEATABLE READ. > >> In an off-list exchange with me, David Fetter expressed opposition to >> this, as a foot-gun. > > I think we've learned over the years that GUCs that significantly change > semantics can be foot-guns. I'm not sure exactly how dangerous this one > would be, but on the whole I'd prefer to avoid introducing a GUC here.
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers