Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1npdas-0000TB-EK for pgsql-docs@arkaria.postgresql.org; Fri, 13 May 2022 22:17:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1npdar-0001mv-By for pgsql-docs@arkaria.postgresql.org; Fri, 13 May 2022 22:17:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1npdaq-0001ji-Q3 for pgsql-docs@lists.postgresql.org; Fri, 13 May 2022 22:17:05 +0000 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1npdao-0004P7-7d for pgsql-docs@lists.postgresql.org; Fri, 13 May 2022 22:17:03 +0000 Received: by mail-ed1-x52e.google.com with SMTP id g23so11421729edy.13 for ; Fri, 13 May 2022 15:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cblc1G7f8IqG4FU9S+lz44OP5e8/JW9QzLoiK2+ISDU=; b=dZXE5wgfKUH+SmtaEc6VV5STvuo1pPgdC/RkkOruouNxsgeopKe8vvrNeW34Qr9BhF VbYoOSXGIF1Wdj3609CVNfTDRqqQlvkznbZYQgAL7bF7Qs61NuLeh2GMn6xhwvYckaSA lxBy2HWXLRjjkVpZvqMrGTPBkTyP7kugiz9qdCWjAqEibDiBG+d8iMpr0tMm+kKn/fVG zHbRQdP9LFTlb/TLM/iTX6R8XUlxf71LDCnyqOIFAMKEr4D01hiQk7MeoyFA75e+Sym/ tXyFLI4LVyaoDKM2kcU4dZ8t+rUtqM+2zbPaeifvfnxnuaPYNUE8MABDrbzfjLG7ceBB PArQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cblc1G7f8IqG4FU9S+lz44OP5e8/JW9QzLoiK2+ISDU=; b=x7MpdxhK1xbG08X6TduZ2EK0k5Gfoifz8ZJg/3G84DnTNowP2HvCmKbzqazMkTukH3 yLC0gOyCFe0z9hJlgk2Itvpomxs9E0JJT94IRadYNNDJy3dU9/LGDrz93cOE37VR2qhW lUg/VSwyfrnSYU+pwegMAo6jq+YDu3gBl8hdyQjL7Sae0u715wQWFelyk+lJZb3qv+Wj tP6GWopkEU5fdPecAoC4Gw7Mv8mNUIUtk26c0Q3ZktTfmvkdYbDezcifRSM/Lsuxqewn TWGWjn9YPraFVCNs24rkmiQVQhjCsjyURROaFVzI1B4JykvoEnsCNq7/Lnx4Ie9n/air U19Q== X-Gm-Message-State: AOAM530bgrpgtfVJi+FZT/Hb/MRrQCo3Mid5c9Ro3JPxgA/aNYp+qUr1 A6BK9EX4lPD3x0nppgJMLkHI//MrHJe00mTXUVA= X-Google-Smtp-Source: ABdhPJwtohabw3Sm4O24gzICjWWOYEVLtJCjcce+Pij8q2XOQihoJeL4O0GodA8r8H/Lq35fLHiGxpn/alzTXZe4VF8= X-Received: by 2002:a50:fa84:0:b0:426:4850:2fc6 with SMTP id w4-20020a50fa84000000b0042648502fc6mr842658edr.38.1652480220125; Fri, 13 May 2022 15:17:00 -0700 (PDT) MIME-Version: 1.0 References: <165222922369.669.10475917322916060899@wrigleys.postgresql.org> <179f4ffe247c3d6c0938217ef85948bcebb97bdb.camel@cybertec.at> In-Reply-To: <179f4ffe247c3d6c0938217ef85948bcebb97bdb.camel@cybertec.at> From: "David G. Johnston" Date: Fri, 13 May 2022 15:16:42 -0700 Message-ID: Subject: Re: correction To: Laurenz Albe Cc: Bruce Momjian , akhilhello@gmail.com, Pg Docs Content-Type: multipart/mixed; boundary="000000000000850ed805deec08e9" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000850ed805deec08e9 Content-Type: multipart/alternative; boundary="000000000000850ed605deec08e7" --000000000000850ed605deec08e7 Content-Type: text/plain; charset="UTF-8" On Fri, May 13, 2022 at 2:49 PM Laurenz Albe wrote: > On Fri, 2022-05-13 at 16:36 -0400, Bruce Momjian wrote: > > On Wed, May 11, 2022 at 12:36:11PM +0200, Laurenz Albe wrote: > > > On Wed, 2022-05-11 at 00:33 +0000, PG Doc comments form wrote: > > > > The following documentation comment has been logged on the website: > > > > > > > > Page: https://www.postgresql.org/docs/14/transaction-iso.html > > > > Description: > > > > > > > > in this page: > https://www.postgresql.org/docs/14/transaction-iso.html > > > > > > > > under the Table 13.1 section, if we search for "phantom reads. > Stricter > > > > behavior is permitted by the SQL standard", do we mean "Looser > behaviour"? > > > > > > What is meant is "The SQL standard allows an implementation to > implement > > > stricter behavior than required by the standard; it only defines the > things > > > that are *not* allowed to happen at a certain isolation level. So it > is for > > > example fine for PostgreSQL not to allow dirty reads in READ > UNCOMMITTED > > > isolation level." > > > > > > Perhaps this could be rewritten to be clearer; it is indeed easy to > > > misunderstand that sentence. > > > > How is this attached patch's wording? > > > > diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml > > index 341fea524a..244694b07f 100644 > > --- a/doc/src/sgml/mvcc.sgml > > +++ b/doc/src/sgml/mvcc.sgml > > @@ -277,8 +277,8 @@ > > > > > > The table also shows that PostgreSQL's Repeatable Read > implementation > > - does not allow phantom reads. Stricter behavior is permitted by the > > - SQL standard: the four isolation levels only define which phenomena > > + does not allow phantom reads. The SQL standard allows more > restrictive > > + behavior: the four isolation levels only define which phenomena > > must not happen, not which phenomena must > happen. > > The behavior of the available isolation levels is detailed in the > > following subsections. > > I think that suffers from the same problem: izt sounds like the standard > allows > stricter behavior than PostgreSQL. > > How about: > > The table also shows that PostgreSQL's Repeatable Read implementation > does not allow phantom reads. That is fine, because the SQL standard > only > specifies which anomalies must not occur at a > certain > isolation level. It is no problem if an implementation provides higher > guarantees than required. > The behavior of the available isolation levels is detailed in the > following subsections. > > > How about this? I really dislike the table having "Allow, but" - it's not allowed and having the reader have to interpret "but" to understand the "not possible" aspect of the cell seems unnecessary. The "in PG" qualification and a note makes it perfectly clear where we deviate from the standard - on the binary option. I also suggest (but did not implement) taking out the mention of the RR exception from here and just leaving the main section where we repeat for a second time what is self-evident from reading the table (so, three mentions of this implementation choice): "This is a stronger guarantee than is required by the SQL standard for this isolation level, and prevents all of the phenomena described in Table 13.1 except for serialization anomalies. As mentioned above, this is specifically allowed by the standard, which only describes the minimum protections each isolation level must provide." David J. - Allowed, but not in PG + Not possible in PG Possible @@ -238,7 +238,7 @@ Not possible - Allowed, but not in PG + Not possible in PG Possible @@ -266,6 +266,12 @@ + + Two entries in the above table are qualified by "in PG". For these, + the SQL standard deems the corresponding anomaly possible at that + isolation level but permits implementations to make it impossible. + --000000000000850ed605deec08e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, May 13, 2022 at 2:49= PM Laurenz Albe <laurenz.al= be@cybertec.at> wrote:
On Fri, 2022-05-13 at 16:36 -0400, Bruce Momjian wrote:
> On Wed, May 11, 2022 at 12:36:11PM +0200, Laurenz Albe wrote:
> > On Wed, 2022-05-11 at 00:33 +0000, PG Doc comments form wrote: > > > The following documentation comment has been logged on the w= ebsite:
> > >
> > > Page: https://www.postgresql.o= rg/docs/14/transaction-iso.html
> > > Description:
> > >
> > > in this page: https://www.post= gresql.org/docs/14/transaction-iso.html
> > >
> > > under the Table 13.1 section, if we search for "phantom= reads. Stricter
> > > behavior is permitted by the SQL standard", do we mean = "Looser behaviour"?
> >
> > What is meant is "The SQL standard allows an implementation = to implement
> > stricter behavior than required by the standard; it only defines = the things
> > that are *not* allowed to happen at a certain isolation level.=C2= =A0 So it is for
> > example fine for PostgreSQL not to allow dirty reads in READ UNCO= MMITTED
> > isolation level."
> >
> > Perhaps this could be rewritten to be clearer; it is indeed easy = to
> > misunderstand that sentence.
>
> How is this attached patch's wording?
>
> diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
> index 341fea524a..244694b07f 100644
> --- a/doc/src/sgml/mvcc.sgml
> +++ b/doc/src/sgml/mvcc.sgml
> @@ -277,8 +277,8 @@
>
>=C2=A0 =C2=A0 =C2=A0<para>
>=C2=A0 =C2=A0 =C2=A0 The table also shows that PostgreSQL's Repeata= ble Read implementation
> -=C2=A0 =C2=A0 does not allow phantom reads.=C2=A0 Stricter behavior i= s permitted by the
> -=C2=A0 =C2=A0 SQL standard: the four isolation levels only define whi= ch phenomena
> +=C2=A0 =C2=A0 does not allow phantom reads.=C2=A0 The SQL standard al= lows more restrictive
> +=C2=A0 =C2=A0 behavior:=C2=A0 the four isolation levels only define w= hich phenomena
>=C2=A0 =C2=A0 =C2=A0 must not happen, not which phenomena <emphasis&= gt;must</emphasis> happen.
>=C2=A0 =C2=A0 =C2=A0 The behavior of the available isolation levels is = detailed in the
>=C2=A0 =C2=A0 =C2=A0 following subsections.

I think that suffers from the same problem: izt sounds like the standard al= lows
stricter behavior than PostgreSQL.

How about:

=C2=A0 The table also shows that PostgreSQL's Repeatable Read implement= ation
=C2=A0 does not allow phantom reads.=C2=A0 That is fine, because the SQL st= andard only
=C2=A0 specifies which anomalies must <emphasis>not</enphasis> = occur at a certain
=C2=A0 isolation level.=C2=A0 It is no problem if an implementation provide= s higher
=C2=A0 guarantees than required.
=C2=A0 The behavior of the available isolation levels is detailed in the =C2=A0 following subsections.



How about this?

I really dislike the table having "Allow, but" - it's not al= lowed and having the reader have to interpret "but" to understand= the "not possible" aspect of the cell seems unnecessary.=C2=A0 T= he "in PG" qualification and a note makes it perfectly clear wher= e we deviate from the standard - on the binary option.

I also suggest (but did not implement) taking out the mention of the RR ex= ception from here and just leaving the main section where we repeat for a s= econd time what is self-evident from reading the table (so, three mentions = of this implementation choice):

"This is a strong= er guarantee than is required by the SQL standard for this isolation level,= and prevents all of the phenomena described in Table 13.1 except for seria= lization anomalies. As mentioned above, this is specifically allowed by the= standard, which only describes the minimum protections each isolation leve= l must provide."

David J.

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<entry>
- =C2=A0 =C2=A0 =C2=A0= =C2=A0 Allowed, but not in PG
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 Not possibl= e in PG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</entry>
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0<entry>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Possible
@@ -238,7 +238,7 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Not = possible
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</entry>
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0<entry>
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 Allo= wed, but not in PG
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 Not possible in PG
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</entry>
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<entry>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Possible@@ -266,6 +266,12 @@
=C2=A0 =C2=A0 =C2=A0 </tgroup>
=C2=A0 = =C2=A0 =C2=A0</table>
=C2=A0
+ =C2=A0 <para>
+ =C2=A0 = =C2=A0Two entries in the above table are qualified by "in PG".=C2= =A0 For these,
+ =C2=A0 =C2=A0the SQL standard deems the corresponding a= nomaly possible at that
+ =C2=A0 =C2=A0isolation level but permits imple= mentations to make it impossible.
+ =C2=A0 </para>
= --000000000000850ed605deec08e7-- --000000000000850ed805deec08e9 Content-Type: application/octet-stream; name="doc-mvcc-transaction-iso.diff" Content-Disposition: attachment; filename="doc-mvcc-transaction-iso.diff" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l34ztvrp0 ZGlmZiAtLWdpdCBhL2RvYy9zcmMvc2dtbC9tdmNjLnNnbWwgYi9kb2Mvc3JjL3NnbWwvbXZjYy5z Z21sCmluZGV4IDM0MWZlYTUyNGEuLjEzN2YwYWIyMDQgMTAwNjQ0Ci0tLSBhL2RvYy9zcmMvc2dt bC9tdmNjLnNnbWwKKysrIGIvZG9jL3NyYy9zZ21sL212Y2Muc2dtbApAQCAtMTk2LDcgKzE5Niw3 IEBACiAgICAgICAgICBSZWFkIHVuY29tbWl0dGVkCiAgICAgICAgIDwvZW50cnk+CiAgICAgICAg IDxlbnRyeT4KLSAgICAgICAgIEFsbG93ZWQsIGJ1dCBub3QgaW4gUEcKKyAgICAgICAgIE5vdCBw b3NzaWJsZSBpbiBQRwogICAgICAgICA8L2VudHJ5PgogICAgICAgICA8ZW50cnk+CiAgICAgICAg ICBQb3NzaWJsZQpAQCAtMjM4LDcgKzIzOCw3IEBACiAgICAgICAgICBOb3QgcG9zc2libGUKICAg ICAgICAgPC9lbnRyeT4KICAgICAgICAgPGVudHJ5PgotICAgICAgICAgQWxsb3dlZCwgYnV0IG5v dCBpbiBQRworICAgICAgICAgTm90IHBvc3NpYmxlIGluIFBHCiAgICAgICAgIDwvZW50cnk+CiAg ICAgICAgIDxlbnRyeT4KICAgICAgICAgIFBvc3NpYmxlCkBAIC0yNjYsNiArMjY2LDEyIEBACiAg ICAgIDwvdGdyb3VwPgogICAgIDwvdGFibGU+CiAKKyAgIDxwYXJhPgorICAgIFR3byBlbnRyaWVz IGluIHRoZSBhYm92ZSB0YWJsZSBhcmUgcXVhbGlmaWVkIGJ5ICJpbiBQRyIuICBGb3IgdGhlc2Us CisgICAgdGhlIFNRTCBzdGFuZGFyZCBkZWVtcyB0aGUgY29ycmVzcG9uZGluZyBhbm9tYWx5IHBv c3NpYmxlIGF0IHRoYXQKKyAgICBpc29sYXRpb24gbGV2ZWwgYnV0IHBlcm1pdHMgaW1wbGVtZW50 YXRpb25zIHRvIG1ha2UgaXQgaW1wb3NzaWJsZS4KKyAgIDwvcGFyYT4KKwogICAgPHBhcmE+CiAg ICAgSW4gPHByb2R1Y3RuYW1lPlBvc3RncmVTUUw8L3Byb2R1Y3RuYW1lPiwgeW91IGNhbiByZXF1 ZXN0IGFueSBvZgogICAgIHRoZSBmb3VyIHN0YW5kYXJkIHRyYW5zYWN0aW9uIGlzb2xhdGlvbiBs ZXZlbHMsIGJ1dCBpbnRlcm5hbGx5IG9ubHkKQEAgLTI3Nyw5ICsyODMsMTAgQEAKIAogICAgPHBh cmE+CiAgICAgVGhlIHRhYmxlIGFsc28gc2hvd3MgdGhhdCBQb3N0Z3JlU1FMJ3MgUmVwZWF0YWJs ZSBSZWFkIGltcGxlbWVudGF0aW9uCi0gICAgZG9lcyBub3QgYWxsb3cgcGhhbnRvbSByZWFkcy4g IFN0cmljdGVyIGJlaGF2aW9yIGlzIHBlcm1pdHRlZCBieSB0aGUKLSAgICBTUUwgc3RhbmRhcmQ6 IHRoZSBmb3VyIGlzb2xhdGlvbiBsZXZlbHMgb25seSBkZWZpbmUgd2hpY2ggcGhlbm9tZW5hCi0g ICAgbXVzdCBub3QgaGFwcGVuLCBub3Qgd2hpY2ggcGhlbm9tZW5hIDxlbXBoYXNpcz5tdXN0PC9l bXBoYXNpcz4gaGFwcGVuLgorICAgIGRvZXMgbm90IGFsbG93IFNRTCBzdGFyZGFyZCBwZXJtaXNz aWJsZSBwaGFudG9tIHJlYWRzLgorICAgPC9wYXJhPgorCisgICA8cGFyYT4KICAgICBUaGUgYmVo YXZpb3Igb2YgdGhlIGF2YWlsYWJsZSBpc29sYXRpb24gbGV2ZWxzIGlzIGRldGFpbGVkIGluIHRo ZQogICAgIGZvbGxvd2luZyBzdWJzZWN0aW9ucy4KICAgIDwvcGFyYT4K --000000000000850ed805deec08e9--