Re: Add a new table for Transaction Isolation?

On Saturday, April 25, 2015, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> On Saturday, April 25, 2015, Kevin Grittner <kgrittn(at)ymail(dot)com
> <javascript:_e(%7B%7D,'cvml','kgrittn(at)ymail(dot)com');>> wrote:
>
>> Bruce Momjian <bruce(at)momjian(dot)us> 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)
>

I'd also consider a 5th column to denote whether a serialization failure
is possible in the first place and then the monitor column would
distinguish between repeatable read and serializable.

David J.