From: Bruce Momjian Date: Fri, 25 Jan 2013 02:44:54 +0000 (-0500) Subject: doc: add mention of ssi read anomolies to mvcc docs X-Git-Tag: REL9_3_BETA1~435 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=56a6317bf54625c7fdade6cd1ab38178bba42448;p=postgresql doc: add mention of ssi read anomolies to mvcc docs From Jeff Davis, modified by Kevin Grittner --- diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml index d5c6076d4a..db820d6f43 100644 --- a/doc/src/sgml/mvcc.sgml +++ b/doc/src/sgml/mvcc.sgml @@ -515,8 +515,9 @@ ERROR: could not serialize access due to concurrent update - The Serializable isolation level provides the strictest transaction - isolation. This level emulates serial transaction execution, + The Serializable isolation level provides + the strictest transaction isolation. This level emulates serial + transaction execution for all committed transactions; as if transactions had been executed one after another, serially, rather than concurrently. However, like the Repeatable Read level, applications using this level must @@ -571,6 +572,20 @@ ERROR: could not serialize access due to read/write dependencies among transact computed by A. + + When relying on Serializable transactions to prevent anomalies, it is + important that any data read from a permanent user table not be + considered valid until the transaction which read it has successfully + committed. This is true even for read-only transactions, except that + data read within a deferrable read-only + transaction is known to be valid as soon as it is read, because such a + transaction waits until it can acquire a snapshot guaranteed to be free + from such problems before starting to read any data. In all other cases + applications must not depend on results read during a transaction that + later aborted; instead, they should retry the transaction until it + succeeds. + + To guarantee true serializability PostgreSQL uses predicate locking, which means that it keeps locks