> I am not entirely sure I understood your question correctly, hopefully I got > it right. I think your question is that this patch only helps if T_1 sets > rgi->killed_for_retry _before_ T_2 executes the above code that does > wait_for_pending_deadlock_kill(). So what if T_1 does so a bit later, after > T_2 has already proceeded beyond this check?
That's so. > > Now consider the second case, where T_1 only sets rgi->killed_for_retry > _after_ T_2 has passed the above code point: > > 1. T_2 acquires some lock inside InnoDB > > 2. T_2 passes the above code point with the check for rgi->killed_for_retry, > it calls mark_start_commit() and starts the commit process. > > 3. T_1 only now gets a lock conflict with T_2, it calls > thd_rpl_deadlock_check(), sets rgi->killed_for_retry, schedules a task for > the manager thread to kill T_2 > > 4. T_1 goes to wait on the lock. > > In this situation, the lock in InnoDB was still held by T_2 when it ran > mark_start_commit(). Hmm, this is unclear. I thought you had a case in which T_2 releases an innodb stats lock at the end of its current statement. And T_1 would try to acquire the lock within that timeframe. Am I confused in the above? It'd be great to have a T_2 worker stack at time of the lock is granted to it, but it's not provided.. Obvisoulsy under this perception T_2 would execute mark_start_commit() after the lock is released. Please clear it out. _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-le...@lists.mariadb.org
