Doc: minor wording adjustments in transaction isolation discussion.

Re-word for more clarity, per gripe from Anton Sidyakin.

Discussion: https://postgr.es/m/168745911769.2239590.6062411529242609290@wrigleys.postgresql.org

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 0adc457f03a0b7b272ae4ff959b5713acecc884a..f8f83d463d4294f72092d83ea12cf7848387cad2 100644 (file)
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -320,8 +320,8 @@
     uses this isolation level, a <command>SELECT</command> query
     (without a <literal>FOR UPDATE/SHARE</literal> clause) sees only data
     committed before the query began; it never sees either uncommitted
-    data or changes committed during query execution by concurrent
-    transactions.  In effect, a <command>SELECT</command> query sees
+    data or changes committed by concurrent transactions during the query's
+    execution.  In effect, a <command>SELECT</command> query sees
     a snapshot of the database as of the instant the query begins to
     run.   However, <command>SELECT</command> does see the effects
     of previous updates executed within its own transaction, even
@@ -488,8 +488,8 @@ COMMIT;
    <para>
     The <firstterm>Repeatable Read</firstterm> isolation level only sees
     data committed before the transaction began; it never sees either
-    uncommitted data or changes committed during transaction execution
-    by concurrent transactions.  (However, the query does see the
+    uncommitted data or changes committed by concurrent transactions during
+    the transaction's execution.  (However, each query does see the
     effects of previous updates executed within its own transaction,
     even though they are not yet committed.)  This is a stronger
     guarantee than is required by the <acronym>SQL</acronym> standard