Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ym81V-0001bP-4t for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 21:54:05 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ym81U-00009v-KL for pgsql-docs@arkaria.postgresql.org; Sat, 25 Apr 2015 21:54:04 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Ym81T-00009p-SD for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 21:54:04 +0000 Received: from mail-ie0-x236.google.com ([2607:f8b0:4001:c03::236]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1Ym81R-0007xY-50 for pgsql-docs@postgresql.org; Sat, 25 Apr 2015 21:54:02 +0000 Received: by iedfl3 with SMTP id fl3so118473602ied.1 for ; Sat, 25 Apr 2015 14:54:00 -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=g+XfxfBa0KYI5MZNCgPeViMCFPXCOCr7QPTs+NwRhNM=; b=G4VQDLhZ8tzO0d5LH6gDD+c221WTr4zL3ZKMfO/N15zZ6kYoFydshlccqh1sy96sDi m4S5FnOGGOo5FpkVuIZ8NfFqaY2flSYcX2TVPY8cnXNZU2NwZrA3Tc0biv5uTQr67Yw0 j1wfiFZWXhtg6fRwh1SPeNbViyZleAi2Rq/XoMRJm6YIDLOqf5TJA4FI/6Ixe0WyInzi iB2z7fFZUJ8NBpwOAO6twXpxA8yHZGNU70zFQOuC8Z/3e/KKQmxwSwhRqilWTU1eG3xA OYPlvV9PxLfbsu6aanG9IStFfSpw0ruGVDNf1COzwr4SE/ZFy4QHn571jM8oMiLMkY8u qjwA== MIME-Version: 1.0 X-Received: by 10.50.147.10 with SMTP id tg10mr5152889igb.36.1429998840122; Sat, 25 Apr 2015 14:54:00 -0700 (PDT) Received: by 10.36.64.15 with HTTP; Sat, 25 Apr 2015 14:54:00 -0700 (PDT) In-Reply-To: References: <20150425200255.GD17791@momjian.us> <279680020.4245099.1429994867712.JavaMail.yahoo@mail.yahoo.com> Date: Sat, 25 Apr 2015 14:54:00 -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=089e0122a2d0e5168d0514938c25 X-Pg-Spam-Score: -1.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 --089e0122a2d0e5168d0514938c25 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, April 25, 2015, David G. Johnston wrote: > 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)" a= nd >> >>>> 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" - t= he > 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. --089e0122a2d0e5168d0514938c25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, April 25, 2015, David G. Johnston <david.g.johnston@gmail.com> wrote:
On Saturday, April 25, 2015, Kevin Grittner <kgrittn@ymail.com> wrote:
Bruce Momjian <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)
<= br>
=C2=A0 I'd=C2=A0also 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.
--089e0122a2d0e5168d0514938c25--