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:09:41 -0700
Message-ID: <CAKFQuwaOJ3bGs-ZmxXVsjkVCJLRJhiBpfBYic7rcbd6cPuDHCA@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-docs>

On Saturday, April 25, 2015, Kevin Grittner <[email protected]> wrote:

> Bruce Momjian <[email protected] <javascript:;>> 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)

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: <CAKFQuwaOJ3bGs-ZmxXVsjkVCJLRJhiBpfBYic7rcbd6cPuDHCA@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