diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 85e4358988..beb44b9b9d 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -3858,21 +3858,16 @@ 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 - version. + partition to another, a concurrent UPDATE or + DELETE may wish to update or delete the same row. + Normally in these circumstances, PostgreSQL + would find the updated version of the row and operate on that + (providing it still matched the query's WHERE + clause). However, with partitioning when the row is moved to another + partition PostgreSQL will instead raise a + serialization failure error (which always returns with an SQLSTATE + value of '40001'). Applications may wish to retry the transaction if + this occurs.