Re: Add a new table for Transaction Isolation?

On Saturday, April 25, 2015, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:

> Bruce Momjian <bruce(at)momjian(dot)us <javascript:;>> wrote:
> > On Sat, Apr 25, 2015 at 07:45:35PM +0000, Kevin Grittner wrote:
>
> >> We could perhaps have the column header say "Non-Serializable
> >> Behavior" or some such; but I think we need to define whatever
> >> term we use for the new column header.
> >
> > I don't think we can define the column as a negative, e.g.
> > "Non-".
>
> Yeah, that would tend to add to confusion. The basic issue is
> whether there are any one-at-a-time orders of execution that could
> yield the same results, or whether there is a cycle in an attempt
> to graph such an order. "Cycles in Apparent Order of Execution"
> would be accurate, but it's kinda long, and possibly too arcane.

"Monitored"?

Are multiple transactions, that do not write to the same rows, monitored so
that read dependencies between them are detected and a serialization error
raised?

>
> >>>> ​Pondering whether something like: "Possible (not in PG)" and
> >>>> avoiding the additional rows would make reading the table
> >>>> easier.
> >>>
> >>> Uh, that's an idea. I thought visually having two separate
> >>> lines was cleaner.
> >>
> >> I think one row per transaction isolation level, with three
> >> possible values per cell, would be the cleanest. I have been
> >> trying to think of alternatives for the three values, but have
> >> not come up with anything better than David's suggestion.
> >
> > Well, then "Possible" would refer to the SQL standard behavior,
> > which seems kind of an odd thing to emphasize there. The field
> > really needs to be "SQL-standard possible, PostgreSQL not
> > possible", but that is too long. This is why I split it into
> > separate lines. We could try "Possible (SQL standard), Not
> > possible (PostgreSQL)".
>
> Yeah, I was searching for some wording that conveyed that the
> standard *allowed* an implementation to present such phenomena at
> the isolation level versus whether the PostgreSQL implementation
> could *actually* present such phenomena. In struggling to come up
> with an analogy, the best I can do is that it's like each person
> fishing for rainbow trout in Wisconsin is *allowed* to keep it if
> it is at least 26 inches long; some people will do so, and some
> catch and release. Regulations say that it is possible to keep it
> (and not be in violation of the rules), but you are not required to
> keep it. For REPEATABLE READ, the SQL standard says that any
> product would be *allowed* to have phantom reads, but is not
> *required* to; we, as a community, choose not to.
>
>
> Maybe something like "Prohibited", "Allowed but not Possible", and
> "Possible"? That would take a little explaining above, since our
> documentation's table would be deviating from the standard's table
> in its word choice.
>
>
Paraphrasing here...

Table # presents the postgresql implementation of the sql standard
isolation levels and notes the additional impermissible behaviors by
including "(contra-SQL)" in the cell. "Contrary to the SQL standard" - the
imprecision in the term seems acceptable.

Not Possible (contra-SQL)