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
This commit is contained in:
Tom Lane 2023-06-28 12:48:14 -04:00
parent b381d96370
commit ac1e974221
1 changed files with 4 additions and 4 deletions

View File

@ -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