diff options
author | Bruce Momjian <bruce@momjian.us> | 2013-01-24 21:44:54 -0500 |
---|---|---|
committer | Bruce Momjian <bruce@momjian.us> | 2013-01-24 21:44:54 -0500 |
commit | 56a6317bf54625c7fdade6cd1ab38178bba42448 (patch) | |
tree | 81dca3af144aa20c739fc5f85523c181c34cf462 | |
parent | 9971f6f5172a8f9525459eb1da840cbc73e6f29f (diff) | |
download | postgresql-56a6317bf54625c7fdade6cd1ab38178bba42448.tar.gz postgresql-56a6317bf54625c7fdade6cd1ab38178bba42448.zip |
doc: add mention of ssi read anomolies to mvcc docs
From Jeff Davis, modified by Kevin Grittner
-rw-r--r-- | doc/src/sgml/mvcc.sgml | 19 |
1 files changed, 17 insertions, 2 deletions
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml index d5c6076d4aa..db820d6f43f 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 </indexterm> <para> - The <firstterm>Serializable</firstterm> isolation level provides the strictest transaction - isolation. This level emulates serial transaction execution, + The <firstterm>Serializable</firstterm> 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 @@ -572,6 +573,20 @@ ERROR: could not serialize access due to read/write dependencies among transact </para> <para> + 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 <firstterm>deferrable</firstterm> 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. + </para> + + <para> To guarantee true serializability <productname>PostgreSQL</productname> uses <firstterm>predicate locking</>, which means that it keeps locks which allow it to determine when a write would have had an impact on |