| Bug #1504 | Mysql crash during select on large MERGE table | ||
|---|---|---|---|
| Submitted: | 8 Oct 2003 19:19 | Modified: | 8 Feb 2005 19:45 |
| Reporter: | Johannes Ullrich | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server: MyISAM storage engine | Severity: | S2 (Serious) |
| Version: | 4.0.15 | OS: | Linux (Linux 2.4.9-e.27summit RedHat AS) |
| Assigned to: | CPU Architecture: | Any | |
[10 Dec 2003 20:30]
Michael Widenius
The only reason (except a hard bug) I can think of regarding this is that you in the MERGE table description have two tables with slightly different keys/fields. Please check that all tables have he same output for SHOW CREATE TABLE ... If the above don't help, please upload to ftp://support.mysql.com/pub/mysql/secret a tar file that contains the .frm files for all involved tables and the .MRG file for the merge file. (We should not need any data to repeat the problem)
[8 Feb 2005 19:45]
Sergei Golubchik
No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you.
Description: Once in a while (sorry, no bullet prove 'redo' instructions), MySQL 4.0.15 crashes during long queries on a large merge table (25 individual tables, 20 Million Rows, and 2-4 Gigbyte per sub-table). The individual tables have been checked with myisamcheck and no error was found. To reproduce: stack trace: 0x8071f64 handle_segfault + 420 0x82916c8 pthread_sighandler + 184 0x824ff51 _mi_check_index + 33 0x8260cdc mi_records_in_range + 28 0x8270a19 myrg_records_in_range + 57 0x80ca584 records_in_range__12ha_myisammrgiPCcUi16ha_rkey_functionT2UiT4 + 52 0x80c0c9e check_quick_keys__FP13st_qsel_paramUiP7SEL_ARGPcUiT3Ui + 1246 0x80c0764 check_quick_select__FP13st_qsel_paramUiP7SEL_ARG + 100 0x80bdb56 test_quick_select__10SQL_SELECTUlUlUlb + 1190 0x8097085 get_quick_record_count__FP10SQL_SELECTP8st_tableUlUl + 53 0x8097a5d make_join_statistics__FP4JOINP13st_table_listP4ItemP16st_dynamic_array + 2477 0x8095c29 mysql_select__FP3THDP13st_table_listRt4List1Z4ItemP4ItemP8st_orderT4T3T4UlP13select_result + 2073 0x80953d6 handle_select__FP3THDP6st_lexP13select_result + 102 0x807c94a mysql_execute_command__Fv + 970 0x8080565 mysql_parse__FP3THDPcUi + 149 0x807bac3 dispatch_command__F19enum_server_commandP3THDPcUi + 1443 0x807b50e do_command__FP3THD + 158 0x807acfe handle_one_connection + 638 0x828ee7c pthread_start_thread + 220 0x82c258a thread_start + 4 system hardware: Dual Xeon MP 1.6 GHz, 8 GByte RAM query that caused the crash (from error log): thd->query at 0x8be5470 = select targetport t, count(*) c,min(date) mindate , max(date) maxdate from reports.reports where source='123.123.123.123' group by t order by c desc limit 0,10 thd->thread_id=97050 key_buffer_size=209715200 read_buffer_size=10481664 max_used_connections=46 max_connections=100 threads_connected=15 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 3276399 K bytes of memory How to repeat: (*) start 'select' on this table (*) start an 'alter table' to add/remove table from the merge table before the 'select' finishes. (*) wait. chances of a crash increase with system load. Suggested fix: haven't found a fix so far.