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