@@ -515,8 +515,9 @@ ERROR: could not serialize access due to concurrent update
515
515
</indexterm>
516
516
517
517
<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;
520
521
as if transactions had been executed one after another, serially,
521
522
rather than concurrently. However, like the Repeatable Read level,
522
523
applications using this level must
@@ -571,6 +572,20 @@ ERROR: could not serialize access due to read/write dependencies among transact
571
572
computed by A.
572
573
</para>
573
574
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
+
574
589
<para>
575
590
To guarantee true serializability <productname>PostgreSQL</productname>
576
591
uses <firstterm>predicate locking</>, which means that it keeps locks
0 commit comments