aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2023-06-28 12:48:14 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2023-06-28 12:48:14 -0400
commitac1e974221cb11465c126097243d5b5050b8d041 (patch)
treea00d9dc1eff3fb1f4a5d3c820bac28658856bd70 /doc/src
parentb381d9637030c163c3b1f8a9d3de51dfc1b4ee58 (diff)
downloadpostgresql-ac1e974221cb11465c126097243d5b5050b8d041.tar.gz
postgresql-ac1e974221cb11465c126097243d5b5050b8d041.zip
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
Diffstat (limited to 'doc/src')
-rw-r--r--doc/src/sgml/mvcc.sgml8
1 files changed, 4 insertions, 4 deletions
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 0adc457f03a..f8f83d463d4 100644
--- 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