From 0cadec788e741d8e9c62944b631adf90c6551911 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 28 Mar 2001 20:46:34 +0000 Subject: [PATCH] Correct erroneous description of MVCC Read Committed semantics. --- doc/src/sgml/mvcc.sgml | 27 +++++++++++++++++---------- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml index c7313fe1a2..d0e020b982 100644 --- a/doc/src/sgml/mvcc.sgml +++ b/doc/src/sgml/mvcc.sgml @@ -1,5 +1,5 @@ @@ -95,7 +95,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.11 2000/12/22 21:51:58 petere The four isolation levels and the corresponding behaviors are described below. - <productname>Postgres</productname> Isolation Levels + <acronym>ANSI</acronym>/<acronym>ISO</acronym> <acronym>SQL</acronym> Isolation LevelsIsolation Levels @@ -192,10 +192,13 @@ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.11 2000/12/22 21:51:58 petere is the default isolation level in Postgres. When a transaction runs on this isolation level, a SELECT query sees only data committed before the - transaction began and never sees either dirty data or concurrent - transaction changes committed during transaction execution. (However, the + query began and never sees either uncommitted data or changes committed + during query execution by concurrent transactions. (However, the SELECT does see the effects of previous updates - executed within this same transaction.) + executed within this same transaction, even though they are not yet + committed.) Notice that two successive SELECTs can see different data, + even though they are within a single transaction, when other transactions + commit changes during execution of the first SELECT. @@ -241,11 +244,15 @@ $Header: /cvsroot/pgsql/doc/src/sgml/mvcc.sgml,v 2.11 2000/12/22 21:51:58 petere When a transaction is on the serializable level, a SELECT query sees only data committed before the - transaction began and never sees either dirty data or concurrent - transaction changes committed during transaction execution. (However, the + transaction began and never sees either uncommitted data or changes + committed + during transaction execution by concurrent transactions. (However, the SELECT does see the effects of previous updates - executed within this same transaction.) This is the same behavior as - for Read Committed level. + executed within this same transaction, even though they are not yet + committed.) This is different from Read Committed in that the + SELECT + sees a snapshot as of the start of the transaction, not as of the start + of the current query within the transaction. @@ -286,7 +293,7 @@ ERROR: Can't serialize access due to concurrent update updates make it impossible to sustain the illusion of serial execution, and the cost of redoing complex transactions may be significant. So this level is recommended only when update queries contain logic - sufficiently complex that it may give wrong answers in Read Committed + sufficiently complex that they may give wrong answers in Read Committed level. -- 2.11.0