Doc: Update the documentation for row movement behavior across partitions.

In commit f16241bef7c, we have changed the behavior for concurrent updates
that move row to a different partition, but forgot to update the docs.
Previously when an UPDATE command causes a row to move from one partition
to another, there is a chance that another concurrent UPDATE or DELETE
misses this row.  However, now we raise a serialization failure error in
such a case.

Reported-by: David Rowley
Author: David Rowley and Amit Kapila
Backpatch-through: 11 where it was introduced
Discussion: https://postgr.es/m/CAKJS1f-iVhGD4-givQWpSROaYvO3c730W8yoRMTF9Gc3craY3w@mail.gmail.com

diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 85e435898823ab4d05dafd81c6c89eee1e15a496..ef713a5a1cfa98f43d38aa631152d83ebf973983 100644 (file)
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -3859,19 +3859,19 @@ ALTER TABLE measurement ATTACH PARTITION measurement_y2008m02
       <para>
        When an <command>UPDATE</command> causes a row to move from one
        partition to another, there is a chance that another concurrent
-       <command>UPDATE</command> or <command>DELETE</command> misses this row.
-       Suppose session 1 is performing an <command>UPDATE</command> on a
-       partition key, and meanwhile a concurrent session 2 for which this row
-       is visible performs an <command>UPDATE</command> or
-       <command>DELETE</command> operation on this row. Session 2 can silently
-       miss the row if the row is deleted from the partition due to session
-       1's activity.  In such case, session 2's
-       <command>UPDATE</command> or <command>DELETE</command>, being unaware of
-       the row movement thinks that the row has just been deleted and concludes
-       that there is nothing to be done for this row. In the usual case where
-       the table is not partitioned, or where there is no row movement,
-       session 2 would have identified the newly updated row and carried out
-       the <command>UPDATE</command>/<command>DELETE</command> on this new row
+       <command>UPDATE</command> or <command>DELETE</command> will get a
+       serialization failure error.  Suppose session 1 is performing an
+       <command>UPDATE</command> on a partition key, and meanwhile a concurrent
+       session 2 for which this row is visible performs an
+       <command>UPDATE</command> or <command>DELETE</command> operation on this
+       row.  In such case, session 2's <command>UPDATE</command> or
+       <command>DELETE</command>, will detect the row movement and raise a
+       serialization failure error (which always returns with an SQLSTATE code
+       '40001').  Applications may wish to retry the transaction if this
+       occurs.  In the usual case where the table is not partitioned, or where
+       there is no row movement, session 2 would have identified the newly
+       updated row and carried out the
+       <command>UPDATE</command>/<command>DELETE</command> on this new row
        version.
       </para>
      </listitem>