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

Amit Kapila · Amit Kapila · commit d850af428deb · 2019-02-07T09:02:45.000+05:30
In commit f16241b, 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
@@ -3359,19 +3359,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>
