From d850af428deb21d074330f6fe801c52e52965fde Mon Sep 17 00:00:00 2001 From: Amit Kapila Date: Thu, 7 Feb 2019 09:02:45 +0530 Subject: [PATCH] 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 5e5c3d7057..f46e61801e 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -3359,19 +3359,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.