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
       
        When an UPDATE causes a row to move from one
        partition to another, there is a chance that another concurrent
-       UPDATE or DELETE misses this row.
-       Suppose session 1 is performing an UPDATE on a
-       partition key, and meanwhile a concurrent session 2 for which this row
-       is visible performs an UPDATE or
-       DELETE 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
-       UPDATE or DELETE, 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 UPDATE/DELETE on this new row
+       UPDATE or DELETE will get a
+       serialization failure error.  Suppose session 1 is performing an
+       UPDATE on a partition key, and meanwhile a concurrent
+       session 2 for which this row is visible performs an
+       UPDATE or DELETE operation on this
+       row.  In such case, session 2's UPDATE or
+       DELETE, 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
+       UPDATE/DELETE on this new row
        version.