Bruce Momjian <bruce@momjian.us> wrote:
> On Sat, Apr 25, 2015 at 11:33:36AM -0700, David G. Johnston wrote:
>> Need to add "Serialization Anomalies" to the previous section's
>> definitions list.
>
> Uh, I am afraid the problem is that "Serialization Anomalies" is
> kind of defined by the standard in an odd way that is specific to
> serializable mode, I think. Kevin, is that true?
They never use the word anomaly (or its plural) in the standard
(even though it is prevalent in the academic literature). See my
earlier email for examples of how the standard describes the issue,
but basically it just boils down to saying that the effects of
concurrent execution of a set of serializable transactions must be
consistent with some one-at-a-time execution order. 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.
>> 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.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
