[Maria-developers] SHOW EXPLAIN and LOCK_thd_data
![](https://secure.gravatar.com/avatar/bccaf81a23eecaecd9feaf01c7c42ff4.jpg?s=120&d=mm&r=g)
Hi Sergei, I've got a problem with SHOW EXPLAIN and LOCK_thd_data. SHOW EXPLAIN was modeled after the KILL command: it's actions are: lock LOCK_thread_count; find the thread $target_thr we need explain for; lock $target_thr->LOCK_thread_count; unlock LOCK_thread_count; send SHOW EXPLAIN request to $target_thr. wait until request is executed (or discarded) unlock $target_thr->LOCK_thread_count; This scheme works, as long as the target thread doesn't select from information_schema tables. With queries over I_S tables, it breaks, because I_S table may try to acquire current_thd->LOCK_thread_count during execution. Below I provide a stacktrace of one such case, line numbers are from lp:~maria-captains/maria/5.5-show-explain. My first thought was to change LOCK_thread_count to be a read/write mutex, but I wanted to hear your opinion, too. (gdb) wher #0 inline_mysql_mutex_lock (that=0xa1111d4, src_file=0x894b75c "sql/sql_class.h", src_line=3020) at include/mysql/psi/mysql_thread.h:608 #1 0x081dda85 in THD::set_open_tables (this=0xa1104b0, open_tables_arg=0xa12de10) at sql/sql_class.h:3020 #2 0x081d9024 in open_table (thd=0xa1104b0, table_list=0xa1289b0, mem_root=0x99134000, ot_ctx=0x99134020) at sql/sql_base.cc:3180 #3 0x081d9aee in open_and_process_table (thd=0xa1104b0, lex=0x9913417c, tables=0xa1289b0, counter=0x991340bc, flags=1026, prelocking_strategy=0x991340c0, has_prelocking_list=false, ot_ctx=0x99134020, new_frm_mem=0x99134000) at sql/sql_base.cc:4509 #4 0x081da269 in open_tables (thd=0xa1104b0, start=0x991340d4, counter=0x991340bc, flags=1026, prelocking_strategy=0x991340c0) at sql/sql_base.cc:4958 #5 0x081da6de in open_normal_and_derived_tables (thd=0xa1104b0, tables=0xa1289b0, flags=1026, dt_phases=34) at sql/sql_base.cc:5617 #6 0x082a3e23 in fill_schema_table_by_open (thd=0xa1104b0, is_show_fields_or_keys=true, table=0xa1263c0, schema_table=0x8c262b0, orig_db_name=0x99134e04, orig_table_name=0x99134e1c, open_tables_state_backup=0x99134d94, can_deadlock=false) at sql/sql_show.cc:3659 #7 0x082b8638 in get_all_tables (thd=0xa1104b0, tables=0xa11d560, cond=0x0) at sql/sql_show.cc:4214 #8 0x0829f943 in do_fill_table (thd=0xa1104b0, table_list=0xa11d560, join_table=0xa128548) at sql/sql_show.cc:7503 #9 0x0829fce2 in get_schema_tables_result (join=0xa1279a8, executed_place=PROCESSED_BY_JOIN_EXEC) at sql/sql_show.cc:7610 #10 0x0829468d in JOIN::exec_inner (this=0xa1279a8) at sql/sql_select.cc:2354 #11 0x082931c8 in JOIN::exec (this=0xa1279a8) at sql/sql_select.cc:2201 BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog
![](https://secure.gravatar.com/avatar/3c2329333dd5898f2e72818af773243d.jpg?s=120&d=mm&r=g)
Hi, Sergei! On May 26, Sergei Petrunia wrote:
I've got a problem with SHOW EXPLAIN and LOCK_thd_data.
SHOW EXPLAIN was modeled after the KILL command: it's actions are:
lock LOCK_thread_count; find the thread $target_thr we need explain for; lock $target_thr->LOCK_thd_data; unlock LOCK_thread_count;
send SHOW EXPLAIN request to $target_thr. wait until request is executed (or discarded)
unlock $target_thr->LOCK_thd_data;
This scheme works, as long as the target thread doesn't select from information_schema tables. With queries over I_S tables, it breaks, because I_S table may try to acquire current_thd->LOCK_thd_data during execution.
Why does it break? If you've acquired thd->LOCK_thd_data before that I_S table query, then it'll wait for you to release it. You release it when you start waiting. And that I_S table query will continue executing, notice your request, etc. If it acquired the mutex before you, you'll wait till it's released, that's all. Regards, Sergei
participants (2)
-
Sergei Golubchik
-
Sergei Petrunia