Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> 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.
Could you draft a proposed doc change? While my ideas have
sometimes influenced the docs, my words don't tend to make it, so
I'm probably not the best candidate to suggest something. (That's
not actually a shocker for me, since I'm a visual thinker, and
getting ideas into words is a bit slow and clumsy for me.)
> 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.
OK.
> It seems much more reasonable to have a
> "serializable_is_repeatable_read" GUC
I'm torn between thinking it would be good to spell it that way and
thinking that we should have "serializable_isolation_implementation"
GUC (or something to that effect) which maps to an enumeration
containing "snapshot" and "ssi". Opinions welcome, since I've put
that GUC at the top of my implementation list. :-)
> that defaults to true for a release, then defaults to false, then
> we may even eventually eliminate it.
If we don't default it to the full serializable mode in the initial
release where that is present, I doubt we ever will. Since most
people seem to use the default READ COMMITTED, and those who are
currently asking for SERIALIZABLE might indeed prefer to get that
(just as a guess with nothing to back it up), I'd be inclined to
argue for changing the behavior of SERIALIZABLE in the first release
where we have true serializable transactions implemented. As for
eventually eliminating it -- who knows? I think we should leave
that to posterity. It really depends on application code we might
break, which is hard to determine.
-Kevin