Re: Add a new table for Transaction Isolation? - Mailing list pgsql-docs

On Saturday, April 25, 2015, Kevin Grittner <kgrittn@ymail.com> wrote:

Bruce Momjian <bruce@momjian.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)