On Tue, Feb 5, 2019 at 2:14 PM David Rowley <david.row...@2ndquadrant.com> wrote: > > The docs in PG11 and master both state: > > 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. > > > Which was true when it was added by Robert in 2f178441044. However, > f16241bef7c then added code to cause serialization failures when the > update/delete process encountered a moved row. >
I agree that the docs need to be updated and this patch should be backpatched as well. However, I think the older wording was more descriptive and clear, so I have modified your patch a bit to retain part of old wording, see the result as attached. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
partition_update_doc_fix_2.patch
Description: Binary data
