Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ym7Kf-0008AC-Vm for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 21:09:50 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ym7Kf-0005Uf-Fh for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 21:09:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Ym7Ke-0005UY-DQ for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 21:09:48 +0000 Received: from mail-ie0-x233.google.com ([2607:f8b0:4001:c03::233]) by magus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Ym7Ka-0006Pa-4b for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 21:09:47 +0000 Received: by iebrs15 with SMTP id rs15so104592738ieb.3 for ; Sat, 25 Apr 2015 14:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B82n1pkMTm35pNroXTpUQ41HqgsDZu4h4n94i5cNihk=; b=Ah6jsX/rdlhI+MzxKNdKMgl4WWfL4tBMiiNH5wyL9xbfyP9ir6mNCFqIREDzpW9v2m tjYBw70Jmol/PCe+NY/ltO511G4FDtAsjOd+LOC9mPYJXALA0c9XTeZTSQxp9r9x09jf tZSjARN8mo+hLu5zLaXBP9wgWMxD/zLqvaMT0T7uJ+e6fTaDwHYG4T+gZWt9gHlETIaW N9p4Hm46nJ5lfKn9yNXGkRrhtPC4XZ45Q3g6mC223pjzBxoNZriovKdjfKR0/z/1zxGy d0gioq+H0LviyPDCIAoSkBTQNRzrxnjTogH59c3vAGwm4sKd34rtENmceZub8tvwRTr1 xskw== MIME-Version: 1.0 X-Received: by 10.107.3.199 with SMTP id e68mr5330107ioi.92.1429996181851; Sat, 25 Apr 2015 14:09:41 -0700 (PDT) Received: by 10.36.64.15 with HTTP; Sat, 25 Apr 2015 14:09:41 -0700 (PDT) In-Reply-To: <279680020.4245099.1429994867712.JavaMail.yahoo@mail.yahoo.com> References: <20150425200255.GD17791@momjian.us> <279680020.4245099.1429994867712.JavaMail.yahoo@mail.yahoo.com> Date: Sat, 25 Apr 2015 14:09:41 -0700 Message-ID: Subject: Re: Add a new table for Transaction Isolation? From: "David G. Johnston" To: Kevin Grittner Cc: Bruce Momjian , Peter Eisentraut , "pgsql-docs@postgresql.org" Content-Type: multipart/alternative; boundary=001a113ed422731680051492ee15 X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org --001a113ed422731680051492ee15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, April 25, 2015, Kevin Grittner wrote: > Bruce Momjian > 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? > > >>>> =E2=80=8BPondering whether something like: "Possible (not in PG)" an= d > >>>> 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) --001a113ed422731680051492ee15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, April 25, 2015, Kevin Grittner <kgrittn@ymail.com> wrote:
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 whateve= r
>> 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.=C2=A0 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.=C2=A0 "Cycles in Apparent Order of Execution&q= uot;
would be accurate, but it's kinda long, and possibly too arcane.

"Monitored"?

Are mu= ltiple transactions, that do not write to the same rows, monitored so that = read dependencies between them are detected and a serialization error raise= d?
=C2=A0

>>>> =E2=80=8BPondering whether something like: "Possible = (not in PG)" and
>>>> avoiding the additional rows would make reading the table<= br> >>>> easier.
>>>
>>> Uh, that's an idea.=C2=A0 I thought visually having two se= parate
>>> lines was cleaner.
>>
>> I think one row per transaction isolation level, with three
>> possible values per cell, would be the cleanest.=C2=A0 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 behavi= or,
> which seems kind of an odd thing to emphasize there.=C2=A0 The field > really needs to be "SQL-standard possible, PostgreSQL not
> possible", but that is too long.=C2=A0 This is why I split it int= o
> separate lines.=C2=A0 We could try "Possible (SQL standard), Not<= br> > 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.=C2=A0 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.=C2=A0 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.=C2=A0 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"?=C2=A0 That would take a little explaining above, sinc= e our
documentation's table would be deviating from the standard's table<= br> in its word choice.


Paraphrasing here...

<= div>Table # presents the postgresql implementation=C2=A0of the sql standard= isolation levels and notes the additional impermissible behaviors by inclu= ding "(contra-SQL)" in the cell. =C2=A0"Contrary to the=C2= =A0SQL standard" - the imprecision in the term seems=C2=A0acceptable.<= /div>

Not Possible (contra-SQL)
--001a113ed422731680051492ee15--