Doc: add some documentation about serialization failure handling.

We weren't very explicit about when to retry such errors.

Simon Riggs

Discussion: https://postgr.es/m/CANbhV-E+u+Z4VBNyJ6GzeO1fd2wP_5S+f6+kmxnN+ALQE6iG9Q@mail.gmail.com

diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index da07f3f6c6c51d12f2cbeb6e84ff240aaa41a421..b4d1e5717050fccf43d41400e12c3599a379b819 100644 (file)
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -588,7 +588,7 @@ ERROR:  could not serialize access due to concurrent update
     applications using this level must
     be prepared to retry transactions due to serialization failures.
     In fact, this isolation level works exactly the same as Repeatable
-    Read except that it monitors for conditions which could make
+    Read except that it also monitors for conditions which could make
     execution of a concurrent set of serializable transactions behave
     in a manner inconsistent with all possible serial (one at a time)
     executions of those transactions.  This monitoring does not
@@ -1720,6 +1720,72 @@ SELECT pg_advisory_lock(q.id) FROM
    
   
 
+  
+   Serialization Failure Handling
+
+   
+    serialization failure
+   
+   
+    retryable error
+   
+
+   
+    Both Repeatable Read and Serializable isolation levels can produce
+    errors that are designed to prevent serialization anomalies.  As
+    previously stated, applications using these levels must be prepared to
+    retry transactions that fail due to serialization errors.  Such an
+    error's message text will vary according to the precise circumstances,
+    but it will always have the SQLSTATE code 40001
+    (serialization_failure).
+   
+
+   
+    It may also be advisable to retry deadlock failures.
+    These have the SQLSTATE code 40P01
+    (deadlock_detected).
+   
+
+   
+    In some cases it is also appropriate to retry unique-key failures,
+    which have SQLSTATE code 23505
+    (unique_violation), and exclusion constraint
+    failures, which have SQLSTATE code 23P01
+    (exclusion_violation).  For example, if the
+    application selects a new value for a primary key column after
+    inspecting the currently stored keys, it could get a unique-key
+    failure because another application instance selected the same new key
+    concurrently.  This is effectively a serialization failure, but the
+    server will not detect it as such because it cannot see
+    the connection between the inserted value and the previous reads.
+    There are also some corner cases in which the server will issue a
+    unique-key or exclusion constraint error even though in principle it
+    has enough information to determine that a serialization problem
+    is the underlying cause.  While it's recommendable to just
+    retry serialization_failure errors unconditionally,
+    more care is needed when retrying these other error codes, since they
+    might represent persistent error conditions rather than transient
+    failures.
+   
+
+   
+    It is important to retry the complete transaction, including all logic
+    that decides which SQL to issue and/or which values to use.
+    Therefore, PostgreSQL does not offer an
+    automatic retry facility, since it cannot do so with any guarantee of
+    correctness.
+   
+
+   
+    Transaction retry does not guarantee that the retried transaction will
+    complete; multiple retries may be needed.  In cases with very high
+    contention, it is possible that completion of a transaction may take
+    many attempts.  In cases involving a conflicting prepared transaction,
+    it may not be possible to make progress until the prepared transaction
+    commits or rolls back.
+   
+  
+
   
    Caveats