postgrespro.git / summary / log / commit / refs

commit    793c736d69091d385a967b2740cc93cfb7a7b076
Author:   Amit Kapila <akapila@postgresql.org>
Date:     Thu Feb 07 03:28:29 2019 +0000

    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


 doc/src/sgml/ddl.sgml | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 85e4358988..ef713a5a1c 100644
--- 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>


[parent: f339a998ffe6]