In the rebased version, the new test cases are added in the existing isolation/specs/partition-key-update-1.spec test.
/*
+* If this is part of an UPDATE of partition-key, the
+* epq tuple will contain the changes from this
+* transaction over and above the updates done by the
+* other transaction. The caller should now use this
+* tuple as its NEW tuple, rather than the earlier NEW
+* tuple.
+*/
+if (epqslot)
+{
+*epqslot = my_epqslot;
+return NULL;
+}
I think we need simmilar fix if there are BR Delete trigger and the ExecDelete is blocked on heap_lock_tuple because the concurrent transaction is updating the same row. Because in such case it would have already got the final tuple so the hep_delete will return MayBeUpdated.
Amit Kapila had pointed (offlist) that you are already trying to fix this issue. I have one more question, Suppose the first time we come for ExecDelete and fire the BR delete trigger and then realize that we need to retry because of the concurrent update. Now, during retry, we realize that because of the latest value we don't need to route the tuple to the different partition so now we will call ExecUpdate and may fire the BRUpdate triggers as well?
