doc: clarify wording about phantom reads

Reported-by: [email protected]
Discussion: https://postgr.es/m/165222922369.669.10475917322916060899@wrigleys.postgresql.org

Backpatch-through: 10

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index c7e402765fcbb7bce61ca7d1e582c8a95c7dbfc0..3df4cda71661dd5aa99d18ffd7fdcd65309660c1 100644 (file)
--- 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>

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 6b025909714a98db60b276fa36fa32ec7ff6d3ea..ff148bb3dcd74aa2111f1b5d69dde1d86e21c7bb 100644 (file)
--- 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</emphasis> occur at certain isolation levels;  higher
+    guarantees are acceptable.
     The behavior of the available isolation levels is detailed in the
     following subsections.
    </para>