public inbox for [email protected]  

help / color / mirror / Atom feed

From: David G. Johnston <[email protected]>
To: Kevin Grittner <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: Add a new table for Transaction Isolation?
Date: Sat, 25 Apr 2015 14:54:00 -0700
Message-ID: <CAKFQuwZ6-FSjmVjtL0ZU1Bq26Bm4TP+Zve5P1AqT_h=jt+uT5w@mail.gmail.com> (raw)
In-Reply-To: <CAKFQuwaOJ3bGs-ZmxXVsjkVCJLRJhiBpfBYic7rcbd6cPuDHCA@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<CAKFQuwaOJ3bGs-ZmxXVsjkVCJLRJhiBpfBYic7rcbd6cPuDHCA@mail.gmail.com>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-docs>

On Saturday, April 25, 2015, David G. Johnston <[email protected]>
wrote:

> On Saturday, April 25, 2015, Kevin Grittner <[email protected]
> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote:
>
>> Bruce Momjian <[email protected]> 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.

view thread (23+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Add a new table for Transaction Isolation?
  In-Reply-To: <CAKFQuwZ6-FSjmVjtL0ZU1Bq26Bm4TP+Zve5P1AqT_h=jt+uT5w@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox