On Mon, 2009-12-28 at 11:54 -0600, Kevin Grittner wrote:
> Serializable transaction isolation is attractive for shops with
> active development by many programmers against a complex schema
> because it guarantees data integrity with very little staff time --
I would like to see true serializability in some form as well.
> Given that each of these would be the best choice for some
> transaction mixes, it might make sense to allow some mapping of the
> four ANSI transaction isolation levels to strategies for
> implementation. At the risk of generating some backlash on this
> particular point, it might allow a Read Committed implementation
> which avoids some of the current anomalies, as a user-selectable
> alternative to the current implementation. As a hypothetical
> example, one might map the ANSI Read Uncommitted mode to what
> PostgreSQL currently calls Read Committed, Read Committed to a
> get-a-new-snapshot strategy, Repeatable Read to SI, and Serializable
> to SSI. (Why do I feel like now would be a good time to duck?)
I like the idea of moving toward using "serializable" for true
serializability, and "repeatable read" for snapshot isolation (perhaps
with a compatibility GUC existing for a while to get the old behavior).
However, I don't know what you mean by "get-a-new-snapshot strategy" or
how it is different from the current read committed behavior. We
obviously want to be careful changing the default isolation level's
behavior.
Regards,Jeff Davis
