Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 56a6317

Browse files
committed
doc: add mention of ssi read anomolies to mvcc docs
From Jeff Davis, modified by Kevin Grittner
1 parent 9971f6f commit 56a6317

File tree

1 file changed

+17
-2
lines changed

1 file changed

+17
-2
lines changed

doc/src/sgml/mvcc.sgml

Lines changed: 17 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -515,8 +515,9 @@ ERROR: could not serialize access due to concurrent update
515515
</indexterm>
516516

517517
<para>
518-
The <firstterm>Serializable</firstterm> isolation level provides the strictest transaction
519-
isolation. This level emulates serial transaction execution,
518+
The <firstterm>Serializable</firstterm> isolation level provides
519+
the strictest transaction isolation. This level emulates serial
520+
transaction execution for all committed transactions;
520521
as if transactions had been executed one after another, serially,
521522
rather than concurrently. However, like the Repeatable Read level,
522523
applications using this level must
@@ -571,6 +572,20 @@ ERROR: could not serialize access due to read/write dependencies among transact
571572
computed by A.
572573
</para>
573574

575+
<para>
576+
When relying on Serializable transactions to prevent anomalies, it is
577+
important that any data read from a permanent user table not be
578+
considered valid until the transaction which read it has successfully
579+
committed. This is true even for read-only transactions, except that
580+
data read within a <firstterm>deferrable</firstterm> read-only
581+
transaction is known to be valid as soon as it is read, because such a
582+
transaction waits until it can acquire a snapshot guaranteed to be free
583+
from such problems before starting to read any data. In all other cases
584+
applications must not depend on results read during a transaction that
585+
later aborted; instead, they should retry the transaction until it
586+
succeeds.
587+
</para>
588+
574589
<para>
575590
To guarantee true serializability <productname>PostgreSQL</productname>
576591
uses <firstterm>predicate locking</>, which means that it keeps locks

0 commit comments

Comments
 (0)