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

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