MDEV-33004 innodb.cursor-restore-locking test fails
THE FIX MUST NOT BE MERGED TO 10.6+, BECAUSE 10.6+ IS NOT AFFECTED! The test is waiting for delete-marked record purging. But this does not happen under the following conditions: 1. "START TRANSACTION WITH CONSISTENT SNAPSHOT" - is active, has not been rolled back yet 2. "DELETE FROM t WHERE b = 20 # trx_1" - is committed 3. "INSERT INTO t VALUES(10, 20) # trx_2" - hanging on "ib_after_row_insert" sync point, waiting for "first_ins_cont" signal 4. "DELETE FROM t WHERE b = 20 # trx_3" - blocked on delete-marked by trx_1 record, waiting for trx_2 5. connection "default" is waiting on 'now WAIT_FOR row_purge_del_mark_finished' purge_coordinator_callback_low() sets purge_state.m_history_length= srv_do_purge(&n_total_purged); even if nothing was purged, like in our case. Nothing was purged because transaction with consistent snapshot was still alive during purging procedure. Then purge_coordinator_timer_callback() does not wake purge thread if the following condition is true: purge_state.m_history_length == trx_sys.rseg_history_len The above condition is true for our case, because we are waiting for delete-marked record purging, and trx_sys.rseg_history_len does not grow. Only 10.5 is affected, because there is no such condition in 10.6, i.e. purge thread is woken up even if history size was not changed during purge coordinator thread suspending. The easiest way to fix it is just to remove the test from 10.5.
Showing
Please register or sign in to comment