|
The reason for this is that the following code almost always causes a deadlock that will eventually be resolved with a timeout:
connection con1;
set debug_sync='statistics_update_start SIGNAL parker WAIT_FOR go1 EXECUTE 1';
set debug_sync='thr_multi_lock_after_thr_lock SIGNAL go2 EXECUTE 2';
use dbt3_s001;
--send analyze table lineitem persistent for all
connection con2;
set debug_sync='open_and_process_table WAIT_FOR parker';
set debug_sync='statistics_read_start SIGNAL go1 WAIT_FOR go2';
use dbt3_s001;
--send select * from mysql.index_stats, lineitem where index_name= 'i_l_shipdate' and l_orderkey=1 and l_partkey=68 order by prefix_arity;
The deadlock happens because the SELECT will first run and take a read lock for index_stats, then the analyze statement will run and tries to take a write lock on table_stats, column_stats and index_stats.
This will block as SELECT already have the lock.
The tests works 'sometimes' depending on lock order in memory, as thr_multi_lock_after_thr_lock was done after the first lock.
Another problem is that the sync point thr_multi_lock_after_thr_lock was hit multiple times by the analyze
thread, which caused the sync point to become inactive before it was time to use it.
Can be fixed by adding a new sync point just before all thr locks and ensuring that thr_multi_lock_before_thr_lock is not triggered for the first call.
This should work as the bug fix for MDEV-3891 will notice that the select should not use statistics for this query and the analyze will continue after the select finishes.
The attached patch fixes these issues
| 
sync.diff