On Tue, Feb 5, 2019 at 2:14 PM David Rowley
<david.rowley@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