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