mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

doc: add mention of ssi read anomolies to mvcc docs

Browse Source 
From Jeff Davis, modified by Kevin Grittner
This commit is contained in:
Bruce Momjian 2013-01-24 21:44:54 -05:00
parent 9971f6f517
commit 56a6317bf5
1 changed files with 17 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
doc/src/sgml/mvcc.sgml
View File

@ -515,8 +515,9 @@ ERROR: could not serialize access due to concurrent update
</indexterm> </indexterm>
<para> <para>
The <firstterm>Serializable</firstterm> isolation level provides the strictest transaction The <firstterm>Serializable</firstterm> isolation level provides
isolation. This level emulates serial transaction execution, the strictest transaction isolation. This level emulates serial
transaction execution for all committed transactions;
as if transactions had been executed one after another, serially, as if transactions had been executed one after another, serially,
rather than concurrently. However, like the Repeatable Read level, rather than concurrently. However, like the Repeatable Read level,
applications using this level must applications using this level must
@ -571,6 +572,20 @@ ERROR: could not serialize access due to read/write dependencies among transact
computed by A. computed by A.
</para> </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> <para>
To guarantee true serializability <productname>PostgreSQL</productname> To guarantee true serializability <productname>PostgreSQL</productname>
uses <firstterm>predicate locking</>, which means that it keeps locks uses <firstterm>predicate locking</>, which means that it keeps locks