Subject: correction

From: PG Doc comments form <[email-masked]>
Date: Wed, 11 May 2022 00:33:43 +0000

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"?

---

From: Laurenz Albe <[email-masked]>
Date: Wed, 11 May 2022 12:36:11 +0200

> 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.

Yours,
Laurenz Albe

---

From: Bruce Momjian <[email-masked]>
Date: Fri, 13 May 2022 16:36:02 -0400

> misunderstand that sentence.

How is this attached patch's wording?

-- 
  Bruce Momjian  <[email-masked]>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Indecision is a decision.  Inaction is an action.  Mark Batterson

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 @@
 
    <para>
     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 <emphasis>must</emphasis> happen.
     The behavior of the available isolation levels is detailed in the
     following subsections.

---

From: Laurenz Albe <[email-masked]>
Date: Fri, 13 May 2022 23:49:09 +0200

> +++ b/doc/src/sgml/mvcc.sgml

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 <emphasis>not</enphasis> 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.

Yours,
Laurenz Albe

---

From: "David G. Johnston" <[email-masked]>
Date: Fri, 13 May 2022 15:16:42 -0700

On Fri, May 13, 2022 at 2:49 PM Laurenz Albe <[email-masked]>
wrote:

> > > > in this page:
> https://www.postgresql.org/docs/14/transaction-iso.html
> > > >
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.

         <entry>
-         Allowed, but not in PG
+         Not possible in PG
         </entry>
         <entry>
          Possible
@@ -238,7 +238,7 @@
          Not possible
         </entry>
         <entry>
-         Allowed, but not in PG
+         Not possible in PG
         </entry>
         <entry>
          Possible
@@ -266,6 +266,12 @@
      </tgroup>
     </table>

+   <para>
+    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.
+   </para>

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 7 Jun 2022 17:07:41 -0400

>   The behavior of the available isolation levels is detailed in the

How is this, attached?

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 341fea524a..112d6ce7a8 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -277,9 +277,10 @@
 
    <para>
     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
-    must not happen, not which phenomena <emphasis>must</emphasis> happen.
+    does not allow phantom reads.  This is acceptable under the SQL
+    standard because the standard specifies which anomalies must
+    <emphasis>not</enphasis> occur at certain isolation levels;  higher
+    guarantees are acceptable.
     The behavior of the available isolation levels is detailed in the
     following subsections.
    </para>

---

From: "David G. Johnston" <[email-masked]>
Date: Tue, 7 Jun 2022 14:40:41 -0700

> How is this, attached?
Works for me.

Capital "S" in Standard as a proper name? (mind grepping this to see how
consistent we are one way or the other, I'm not setup for that at the
moment)

David J.

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 7 Jun 2022 19:51:20 -0400

On Tue, Jun  7, 2022 at 02:40:41PM -0700, David G. Johnston wrote:
> consistent we are one way or the other, I'm not setup for that at the moment)

Well, that's a good question.  Seems we use "SQL standard", and I found
one place where we capitalize "Standard", so fixed too in this patch.

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index c7e402765f..3df4cda716 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -2194,7 +2194,7 @@ HINT:  You can then restart the server after making the necessary configuration
     Currently, temporary table creation is not allowed during read-only
     transactions, so in some cases existing scripts will not run correctly.
     This restriction might be relaxed in a later release. This is
-    both an SQL Standard compliance issue and a technical issue.
+    both an SQL standard compliance issue and a technical issue.
    </para>
 
    <para>
 
    <para>

---

From: "David G. Johnston" <[email-masked]>
Date: Tue, 7 Jun 2022 16:53:04 -0700

> one place where we capitalize "Standard", so fixed too in this patch.

+1

Thanks!

David J.

---

From: Tom Lane <[email-masked]>
Date: Tue, 07 Jun 2022 20:00:16 -0400

> +    <emphasis>not</enphasis> occur at certain isolation levels;  higher

The docs toolchain is not gonna like that.

			regards, tom lane

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 7 Jun 2022 20:26:25 -0400

> The docs toolchain is not gonna like that.

You are correct.  I should have tested, updated patch attached.

 
    <para>
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 341fea524a..c9c4f943c9 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -277,9 +277,10 @@
 
    <para>
+    <emphasis>not</emphasis> occur at certain isolation levels;  higher

---

From: "David G. Johnston" <[email-masked]>
Date: Thu, 9 Jun 2022 16:18:07 -0700

> You are correct.  I should have tested, updated patch attached.
I can confirm the build and am still good with the content.

David J.

---

From: Bruce Momjian <[email-masked]>
Date: Wed, 22 Jun 2022 14:33:51 -0400

> one place where we capitalize "Standard", so fixed too in this patch.

Applied to all supported branches.