On Sun, Jan 9, 2011 at 7:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@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
