On Tue, Feb 6, 2018 at 9:19 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Sun, Feb 4, 2018 at 3:41 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> It is not clear to me what is exactly your concern if we try to follow >>> #2? To me, #2 seems like a natural choice. >> >> At first, but it gives an anomaly so is not a good choice. The patch >> does behavior #5, it rechecks the conditions with the latest row. >> >> Otherwise >> WHEN MATCHED AND a=0 THEN UPDATE SET b=0 >> WHEN MATCHED AND a=1 THEN UPDATE SET b=1 >> would result in (a=1, b=0) in case of concurrent updates, which the >> user clearly doesn't want. > > I am unable to understand this. >
Neither do I. There is nothing in above statement which changes 'a'. > What are you presuming the tuple was > originally? > I have tried to think of one example which can result in what Simon is saying. Consider original tuple has a = 0 and b = 1 Session -1 WHEN MATCHED AND a=0 THEN UPDATE SET b=0 WHEN MATCHED AND a=1 THEN UPDATE SET b=1 Session-2 WHEN MATCHED AND b=0 THEN UPDATE SET a=0 WHEN MATCHED AND b=1 THEN UPDATE SET a=1 Now assume both the session got the tuple to Update, Session-1 locks to Update b = 0 and Session-2 will wait for Session-1 to complete. After Session-1 commits, Session-2 will wake up and performs EvalPlanQual because it will find the tuple as Updated. Now, I think EvalPlanQual mechanism will succeed if we don't match WHEN clauses as part of EvalPlanQual mechanism and it will update a = 1. So, now we will have a=1, b=0. I think if this is going to happen with approach-2 (#2), then one can argue that Session-2's update shouldn't have succeeded. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
