mirrors
/
postgres
mirror of https://github.com/postgres/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
doc/src/sgml/mvcc.sgml
View File

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