Comment 8 for bug 1018685

Hi Raghavendra, thanks for the deep thought and feedback of this patch. If update result is failed as duplicate key error, we did not use the "delete and then update" strategy, so the what exactly as you tested, you could refer to the second patch(only HA_ERR_KEY_NOT_FOUND is handled):

@@ -9782,13 +9810,30 @@ Update_rows_log_event::do_exec_row(const
+ if ((slave_exec_mode == SLAVE_EXEC_MODE_SMART) &&
+ (error == HA_ERR_KEY_NOT_FOUND)) {

That's the unfinished part of that patch, even it's used well in our product environment, as we did not update PK in most of APPs of Alibaba.

Why we did not handle such situation, my thought is:
No matter update failed as UNIQ_KEY or PRIMARY_KEY( both return as DUP_KEY), the after image of update event is really conflict with the existing records in table. Then, how should we handle such scenario?
1) If failed as UNIQ_KEY, then the existing record R' already with the UNIQ_KEY should not be change, so the only way we could do is to ignore the UNIQ_KEY columns in record R, just update the rest columns.
2) If failed as PRIMARY_KEY, we might update the conflicted record with after image of update event and then delete the old record R by before image of update event.

Lots of changes should be done, such as split UNIQ_KEY and PRIMARY_KEY from DUP_KEY in some functions, and the risk of code change enlarged much. What's more, the record after handle of #1 and #2 is not really correct for slave. That's the reason why did not do it yet.