@@ -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