On Saturday, April 25, 2015, David G. Johnston <david.g.johns...@gmail.com> wrote:
> On Saturday, April 25, 2015, Kevin Grittner <kgri...@ymail.com > <javascript:_e(%7B%7D,'cvml','kgri...@ymail.com');>> wrote: > >> Bruce Momjian <br...@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) > 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.
