Re: Serializable implementation

On Mon, 2009-12-28 at 11:54 -0600, Kevin Grittner wrote:
> 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 think we should document that REPEATABLE READ is SI, and encourage
people to use it rather than SERIALIZABLE if they want SI. Also,
document that SERIALIZABLE may be changed in the future to be truly
serializable, and that may have a performance penalty and cause
serialization errors more frequently.

Documenting it in 8.5 gives us a little more freedom to change the
behavior of SERIALIZABLE over the next few releases.

I also don't think we should plan to change READ COMMITTED mode at all,
even with a GUC. The only mode we should change is SERIALIZABLE. The
reason is that READ COMMITTED is now the default, and I don't think it's
realistic that we'll ever change its semantics (I suppose we could
change the default isolation mode to READ UNCOMMITTED, but I'm not sure
that's a good idea either). A compatibility GUC is one thing, but a
behavior-changing GUC that lasts forever -- and more importantly, would
default to the _old_ behavior forever -- is highly undesirable (to me at
least).

It seems much more reasonable to have a
"serializable_is_repeatable_read" GUC that defaults to true for a
release, then defaults to false, then we may even eventually eliminate
it.

Regards,
Jeff Davis