From ac1e974221cb11465c126097243d5b5050b8d041 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 28 Jun 2023 12:48:14 -0400 Subject: [PATCH] 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 --- doc/src/sgml/mvcc.sgml | 8 ++++---- 1 file 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 SELECT query (without a FOR UPDATE/SHARE 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 SELECT query sees + data or changes committed by concurrent transactions during the query's + execution. In effect, a SELECT query sees a snapshot of the database as of the instant the query begins to run. However, SELECT does see the effects of previous updates executed within its own transaction, even @@ -488,8 +488,8 @@ COMMIT; The Repeatable Read 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 SQL standard -- 2.39.5