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 3ee6553c3447f2a5640c5552804a5bb44ebe9269..c21d7a75626c016d3b779eaaf5a9ddb8b04f1b27 100644 (file)
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -2315,7 +2315,7 @@ LOG:  database system is ready to accept read only connections
     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 a SQL Standard compliance issue and a technical issue.
+    both a 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 de91a85e5e8a4acd3a87031cbf0e647764ff38e9..71cb4d2bc3e1c4baa3b8a066fe308befc7dd5068 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</> 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>