![](https://secure.gravatar.com/avatar/8de06d9848eaa0795ab6917a363747eb.jpg?s=120&d=mm&r=g)
hi Jeremy,
I can not give a test case because I have changed the way of retrying transaction in mysql-5.5.30 and then found this problem. The mysql-5.5.30 SQL thread's original way that retry failed events group(or a transaction) is droping the failed log-event object, then reading group's log events from BEGIN in relay log and applying their objects one by one again.for the log-event objects is new, the process of retry can get the same result as last time.
But in parallel replication of dingqi's patch the retry-way is changed. It reads in all events of a group and build a list of log-event objects in a time , then call log events' do_apply_event function from the event-object list head to tail. If there is some error happened, the retry-way is calling log events' do_apply_event function from the event-object list head again. so a log event object could do do_apply_event() twice. I imitated this process in mysql-5.5.30, made a log event object do do_apply_event() twice when it first time return nozero. then I find this problem that a Rows_log_event::do_apply_event() could call twice but return different results(first time is nozero, while second is zero). I also find the reason why the second time return zero is m_curr_row==m_rows_end in the Rows_log_event object. Does it need to set m_curr_row back to its original value before return from Rows_log_event::do_apply_event().
Regards,
Rao
2013-07-16
nanyi607rao
Hi,
Do you have a test case (or sequence of SQL statements you could provide in email)? Your email is a bit hard to follow, but this sounds interesting.
Regards,
Jeremy
On Thu, Jul 11, 2013 at 11:51 PM, nanyi607rao