Description:
If a server is running with --log-output=table, on restart after an unclean shutdown it attempts to perform recovery on the CSV log tables. Unlike the recovery of InnoDB tables, this process happens without any notice in the log. The user sees an unexplainable hang in the client as he tries to issue his first query after the restart, and 100% CPU usage with the following backtrace:
#0 0x00000000008d1f28 in Transparent_file::get_value (this=0x226a430, offset=47516761) at transparent_file.cc:86
#1 0x00000000008ce5cf in find_eoln_buff (data_buff=0x226a430, begin=47516685, end=101085921, eoln_len=0x7f70df4c8e6c) at ha_tina.cc:409
#2 0x00000000008ce715 in ha_tina::find_current_row (this=0x2391280, buf=0x234e4f8 '╔' <repeats 200 times>...) at ha_tina.cc:604
#3 0x00000000008cf0e9 in ha_tina::repair (this=0x2391280, thd=0x2329e88, check_opt=0x7f70df4c91c0) at ha_tina.cc:1467
#4 0x00000000008d031d in ha_tina::check_and_repair (this=0x2391280, thd=0x2329e88) at ha_tina.cc:325
#5 0x00000000007d6bd5 in handler::ha_check_and_repair (this=0x2391280, thd=0x2329e88) at handler.cc:3299
#6 0x00000000006e0166 in auto_repair_table (thd=0x2329e88, table_list=0x7f70df4c9840) at sql_base.cc:3607
#7 0x00000000006e04f8 in Open_table_context::recover_from_failed_open_table_attempt (this=0x7f70df4c9740, thd=0x2329e88, table=0x7f70df4c9840)
at sql_base.cc:3732
#8 0x00000000006e19b9 in open_ltable (thd=0x2329e88, table_list=0x7f70df4c9840, lock_type=TL_WRITE_CONCURRENT_INSERT, lock_flags=27) at sql_base.cc:4658
#9 0x00000000006e1d2e in open_performance_schema_table (thd=0x2329e88, one_table=0x7f70df4c9840, backup=0x7f70df4c9ff0) at sql_base.cc:8670
#10 0x000000000076be6f in Log_to_csv_event_handler::log_general (this=0x2148be0, thd=0x2329e88, event_time=1261055806,
user_host=0x7f70df4ca110 "root[root] @ localhost [127.0.0.1]", user_host_len=34, thread_id=1, command_type=0xb74f58 "Connect", command_type_len=7,
sql_text=0x7f70df4ca390 "root@localhost on test", sql_text_len=22, client_cs=0x1078880) at log.cc:473
#11 0x0000000000768b7f in LOGGER::general_log_write (this=0x108a4e0, thd=0x2329e88, command=COM_CONNECT, query=0x7f70df4ca390 "root@localhost on test",
query_length=22) at log.cc:2075
#12 0x0000000000768ccd in LOGGER::general_log_print (this=0x108a4e0, thd=0x2329e88, command=COM_CONNECT, format=0xb7351f "%s@%s on %s", args=0x7f70df4ca7e0)
at log.cc:2094
#13 0x0000000000768df0 in general_log_print (thd=0x2329e88, command=COM_CONNECT, format=0xb7351f "%s@%s on %s") at log.cc:6273
#14 0x000000000067b019 in check_user (thd=0x2329e88, command=COM_CONNECT, passwd=0x2374fbe "test", passwd_len=0, db=0x7f70df4caea0 "test", check_count=true)
at sql_connect.cc:436
#15 0x000000000067c437 in check_connection (thd=0x2329e88) at sql_connect.cc:923
#16 0x000000000067c4d6 in login_connection (thd=0x2329e88) at sql_connect.cc:981
#17 0x000000000067c68f in handle_one_connection (arg=0x2329e88) at sql_connect.cc:1152
#18 0x000000315b0073da in start_thread () from /lib64/libpthread.so.0
#19 0x000000315a4e627d in clone () from /lib64/libc.so.6
How to repeat:
Code inspection
Suggested fix:
Automatic repair of CSV tables should be announced in the error log the way InnoDB recovery is.
Description: If a server is running with --log-output=table, on restart after an unclean shutdown it attempts to perform recovery on the CSV log tables. Unlike the recovery of InnoDB tables, this process happens without any notice in the log. The user sees an unexplainable hang in the client as he tries to issue his first query after the restart, and 100% CPU usage with the following backtrace: #0 0x00000000008d1f28 in Transparent_file::get_value (this=0x226a430, offset=47516761) at transparent_file.cc:86 #1 0x00000000008ce5cf in find_eoln_buff (data_buff=0x226a430, begin=47516685, end=101085921, eoln_len=0x7f70df4c8e6c) at ha_tina.cc:409 #2 0x00000000008ce715 in ha_tina::find_current_row (this=0x2391280, buf=0x234e4f8 '╔' <repeats 200 times>...) at ha_tina.cc:604 #3 0x00000000008cf0e9 in ha_tina::repair (this=0x2391280, thd=0x2329e88, check_opt=0x7f70df4c91c0) at ha_tina.cc:1467 #4 0x00000000008d031d in ha_tina::check_and_repair (this=0x2391280, thd=0x2329e88) at ha_tina.cc:325 #5 0x00000000007d6bd5 in handler::ha_check_and_repair (this=0x2391280, thd=0x2329e88) at handler.cc:3299 #6 0x00000000006e0166 in auto_repair_table (thd=0x2329e88, table_list=0x7f70df4c9840) at sql_base.cc:3607 #7 0x00000000006e04f8 in Open_table_context::recover_from_failed_open_table_attempt (this=0x7f70df4c9740, thd=0x2329e88, table=0x7f70df4c9840) at sql_base.cc:3732 #8 0x00000000006e19b9 in open_ltable (thd=0x2329e88, table_list=0x7f70df4c9840, lock_type=TL_WRITE_CONCURRENT_INSERT, lock_flags=27) at sql_base.cc:4658 #9 0x00000000006e1d2e in open_performance_schema_table (thd=0x2329e88, one_table=0x7f70df4c9840, backup=0x7f70df4c9ff0) at sql_base.cc:8670 #10 0x000000000076be6f in Log_to_csv_event_handler::log_general (this=0x2148be0, thd=0x2329e88, event_time=1261055806, user_host=0x7f70df4ca110 "root[root] @ localhost [127.0.0.1]", user_host_len=34, thread_id=1, command_type=0xb74f58 "Connect", command_type_len=7, sql_text=0x7f70df4ca390 "root@localhost on test", sql_text_len=22, client_cs=0x1078880) at log.cc:473 #11 0x0000000000768b7f in LOGGER::general_log_write (this=0x108a4e0, thd=0x2329e88, command=COM_CONNECT, query=0x7f70df4ca390 "root@localhost on test", query_length=22) at log.cc:2075 #12 0x0000000000768ccd in LOGGER::general_log_print (this=0x108a4e0, thd=0x2329e88, command=COM_CONNECT, format=0xb7351f "%s@%s on %s", args=0x7f70df4ca7e0) at log.cc:2094 #13 0x0000000000768df0 in general_log_print (thd=0x2329e88, command=COM_CONNECT, format=0xb7351f "%s@%s on %s") at log.cc:6273 #14 0x000000000067b019 in check_user (thd=0x2329e88, command=COM_CONNECT, passwd=0x2374fbe "test", passwd_len=0, db=0x7f70df4caea0 "test", check_count=true) at sql_connect.cc:436 #15 0x000000000067c437 in check_connection (thd=0x2329e88) at sql_connect.cc:923 #16 0x000000000067c4d6 in login_connection (thd=0x2329e88) at sql_connect.cc:981 #17 0x000000000067c68f in handle_one_connection (arg=0x2329e88) at sql_connect.cc:1152 #18 0x000000315b0073da in start_thread () from /lib64/libpthread.so.0 #19 0x000000315a4e627d in clone () from /lib64/libc.so.6 How to repeat: Code inspection Suggested fix: Automatic repair of CSV tables should be announced in the error log the way InnoDB recovery is.