This doesn't add any new information, but perhaps eases the reader
into this long section. It also gives the discussion of plain SELECT
its own paragraph, better paralleling the subsequent paragraphs.
From b02c18896e4590eff6b396cd0faedac62b29bf68 Mon Sep 17 00:00:00 2001
From: Will Mortensen <w...@extrahop.com>
Date: Fri, 26 Aug 2022 23:08:44 -0700
Subject: [PATCH 5/6] doc: add brief summary of Read Committed
---
doc/src/sgml/mvcc.sgml | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 029c25232c..96bcc8c3ac 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -316,8 +316,18 @@
<para>
<firstterm>Read Committed</firstterm> is the default isolation
- level in <productname>PostgreSQL</productname>. When a transaction
- uses this isolation level, a <command>SELECT</command> query
+ level in <productname>PostgreSQL</productname>. Within a transaction at
this
+ isolation level, each command starts with a new snapshot that includes the
+ effects of all transactions committed up to that instant, as well as the
+ effects of the previous commands in the current transaction. As described
in
+ more detail below, commands that only read from the database simply see its
+ state at the time of this snapshot, but commands that modify or lock
+ rows may inconsistently observe the effects of any transactions that
+ commit while the command is executing.
+ </para>
+
+ <para>
+ 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
--
2.25.1
