| Bug #37362 | Crash in do_field_eq | ||
|---|---|---|---|
| Submitted: | 12 Jun 2008 11:30 | Modified: | 3 Aug 2009 23:05 |
| Reporter: | Philip Stoev | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Optimizer | Severity: | S1 (Critical) |
| Version: | 6.0-falcon, 5.0, 5.1, 6.0 bzr | OS: | Any |
| Assigned to: | Gleb Shchepa | CPU Architecture: | Any |
| Tags: | regression | ||
[2 Sep 2008 13:37]
Philip Stoev
Setting to open so that the bug verification team can take over.
[23 Mar 2009 21:38]
Sveta Smirnova
Thank you for the report.
Verified as described.
Backtrace from 5.1:
Thread 1 (process 4827):
#0 0x002ce402 in __kernel_vsyscall ()
#1 0x0046264f in pthread_kill () from /lib/libpthread.so.0
#2 0x085a46c5 in my_write_core (sig=11) at stacktrace.c:310
#3 0x0824c685 in handle_segfault (sig=11) at mysqld.cc:2513
#4 <signal handler called>
#5 0x08190d80 in Item_field::print (this=0xa295ae0, str=0xb2b0c3f4, query_type=QT_ORDINARY) at item.cc:5434
#6 0x0816f657 in st_select_lex::print_order (str=0xb2b0c3f4, order=0xa28ac58, query_type=QT_ORDINARY) at sql_lex.cc:1985
#7 0x082eef48 in st_select_lex::print (this=0xa289638, thd=0xa230c78, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_select.cc:16634
#8 0x08207766 in subselect_single_select_engine::print (this=0xa2854a8, str=0xb2b0c3f4, query_type=QT_ORDINARY) at item_subselect.cc:2438
#9 0x0820153f in Item_subselect::print (this=0xa285420, str=0xb2b0c3f4, query_type=QT_ORDINARY) at item_subselect.cc:317
#10 0x081842c1 in Item::print_item_w_name (this=0xa285420, str=0xb2b0c3f4, query_type=QT_ORDINARY) at item.cc:451
#11 0x082eedbe in st_select_lex::print (this=0xa289238, thd=0xa230c78, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_select.cc:16595
#12 0x0816f786 in st_select_lex_unit::print (this=0xa2893c8, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_lex.cc:1953
#13 0x082ee6ab in TABLE_LIST::print (this=0xa285d48, thd=0xa230c78, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_select.cc:16487
#14 0x082ee9f6 in print_join (thd=0xa230c78, str=0xb2b0c3f4, tables=0xa2320d4, query_type=QT_ORDINARY) at sql_select.cc:16390
#15 0x082eee2a in st_select_lex::print (this=0xa232010, thd=0xa230c78, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_select.cc:16606
#16 0x0816f786 in st_select_lex_unit::print (this=0xa231da0, str=0xb2b0c3f4, query_type=QT_ORDINARY) at sql_lex.cc:1953
#17 0x0825b7d0 in execute_sqlcom_select (thd=0xa230c78, all_tables=0xa285d48) at sql_parse.cc:4895
#18 0x08261be1 in mysql_execute_command (thd=0xa230c78) at sql_parse.cc:2204
#19 0x0826af74 in mysql_parse (thd=0xa230c78,
inBuf=0xa288cc0 "EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG(\nint_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey LIMIT 20 ) AS X WHERE X\n. int_nokey < 83 GROUP"..., length=317, found_semicolon=0xb2b0d2fc) at sql_parse.cc:5831
#20 0x0826bbb0 in dispatch_command (command=COM_QUERY, thd=0xa230c78, packet=0xb2a7d021 "", packet_length=317) at sql_parse.cc:1216
#21 0x0826cdce in do_command (thd=0xa230c78) at sql_parse.cc:857
#22 0x08259a05 in handle_one_connection (arg=0xa230c78) at sql_connect.cc:1115
#23 0x0045fbd4 in start_thread () from /lib/libpthread.so.0
#24 0x003b74fe in clone () from /lib/libc.so.6
[23 Mar 2009 21:40]
Sveta Smirnova
6.0 backtrace like 5.1 in my case:
#0 0x002ce402 in __kernel_vsyscall ()
#0 0x002ce402 in __kernel_vsyscall ()
#1 0x0046264f in pthread_kill () from /lib/libpthread.so.0
#2 0x088240fb in my_write_core (sig=11) at stacktrace.c:309
#3 0x082bf3a0 in handle_segfault (sig=11) at mysqld.cc:2689
#4 <signal handler called>
#5 0x082004c4 in Item_field::print (this=0xa7990f8, str=0xa7f0d084, query_type=QT_ORDINARY) at item.cc:5624
#6 0x081df05b in st_select_lex::print_order (str=0xa7f0d084, order=0xa5f4128, query_type=QT_ORDINARY) at sql_lex.cc:2055
#7 0x083702e8 in st_select_lex::print (this=0xa5b72d8, thd=0xa5ba5b8, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_select.cc:22125
#8 0x08277b50 in subselect_single_select_engine::print (this=0xa5f4258, str=0xa7f0d084, query_type=QT_ORDINARY) at item_subselect.cc:2783
#9 0x08271a51 in Item_subselect::print (this=0xa5f41b8, str=0xa7f0d084, query_type=QT_ORDINARY) at item_subselect.cc:383
#10 0x081f34a7 in Item::print_item_w_name (this=0xa5f41b8, str=0xa7f0d084, query_type=QT_ORDINARY) at item.cc:450
#11 0x0837015e in st_select_lex::print (this=0xa5b6ea8, thd=0xa5ba5b8, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_select.cc:22086
#12 0x081df18a in st_select_lex_unit::print (this=0xa5b7040, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_lex.cc:2023
#13 0x0836f999 in TABLE_LIST::print (this=0xa5f4d90, thd=0xa5ba5b8, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_select.cc:21978
#14 0x0836fc48 in print_table_array (thd=0xa5ba5b8, str=0xa7f0d084, table=0xa7996c8, end=0xa7996cc) at sql_select.cc:21834
#15 0x0836febe in print_join (thd=0xa5ba5b8, str=0xa7f0d084, tables=0xa5bb8b0, query_type=QT_ORDINARY) at sql_select.cc:21903
#16 0x083701ca in st_select_lex::print (this=0xa5bb7ec, thd=0xa5ba5b8, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_select.cc:22097
#17 0x081df18a in st_select_lex_unit::print (this=0xa5bb554, str=0xa7f0d084, query_type=QT_ORDINARY) at sql_lex.cc:2023
#18 0x082ce382 in execute_sqlcom_select (thd=0xa5ba5b8, all_tables=0xa5f4d90) at sql_parse.cc:4752
#19 0x082d4017 in mysql_execute_command (thd=0xa5ba5b8) at sql_parse.cc:2069
#20 0x082dced3 in mysql_parse (thd=0xa5ba5b8,
inBuf=0xa5b66c8 "EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG(\nint_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey LIMIT 20 ) AS X WHERE X\n. int_nokey < 83 GROUP"..., length=317, found_semicolon=0xa7f0df20) at sql_parse.cc:5783
#21 0x082dd915 in dispatch_command (command=COM_QUERY, thd=0xa5ba5b8, packet=0xa7e7e021 "", packet_length=317) at sql_parse.cc:1009
#22 0x082dec79 in do_command (thd=0xa5ba5b8) at sql_parse.cc:691
#23 0x082cca67 in handle_one_connection (arg=0xa5ba5b8) at sql_connect.cc:1146
#24 0x0045fbd4 in start_thread () from /lib/libpthread.so.0
#25 0x003b74fe in clone () from /lib/libc.so.6
[23 Mar 2009 21:42]
Sveta Smirnova
shorter test
Attachment: bug37362.test (application/octet-stream, text), 379.17 KiB.
[24 Mar 2009 6:50]
Sveta Smirnova
Bug was repeatable with version 5.1.23, then not repeatable with versions 5.1.30-5.1.32 (didn't check when it was reintroduced though) and 6.0.8, then repeatable again with current development sources.
[24 Mar 2009 17:12]
Sveta Smirnova
Bug is repeatable with current 5.0, 5.1 and 6.0 sources.
[1 Apr 2009 21:56]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/71146 2722 Gleb Shchepa 2009-04-02 Bug #37362: Crash in do_field_eq EXPLAIN EXTENDED of nested query containing a error: 1054 Unknown column '...' in 'field list' may cause a server crash. Parse error like described above forces a call to JOIN::destroy() on malformed subquery. That JOIN::destroy function closes and frees temporary tables. However, temporary fields of these tables may be listed in st_select_lex::group_list of outer query, and that st_select_lex may not cleanup them properly. So, after the JOIN::destroy call that st_select_lex::group_list may have Item_field objects with dangling pointers to freed temporary table Field objects. That caused a crash. To prevent dangling pointers, 1) a list of temporary table fields has been added to JOIN class; 2) JOIN::destroy has been modified to cleanup temporary table fields. modified: mysql-test/r/subselect3.result mysql-test/t/subselect3.test sql/sql_select.cc sql/sql_select.h
[3 Apr 2009 15:44]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/71332 2722 Gleb Shchepa 2009-04-03 Bug #37362: Crash in do_field_eq EXPLAIN EXTENDED of nested query containing a error: 1054 Unknown column '...' in 'field list' may cause a server crash. Parse error like described above forces a call to JOIN::destroy() on malformed subquery. That JOIN::destroy function closes and frees temporary tables. However, temporary fields of these tables may be listed in st_select_lex::group_list of outer query, and that st_select_lex may not cleanup them properly. So, after the JOIN::destroy call that st_select_lex::group_list may have Item_field objects with dangling pointers to freed temporary table Field objects. That caused a crash. modified: mysql-test/r/subselect3.result mysql-test/t/subselect3.test sql/sql_select.cc
[29 Apr 2009 18:15]
Timour Katchaounov
Review discussion with Gleb:
<timour> gleb, quick question
<timour> in
<timour> JOIN::destroy()
<timour> you added:
<timour> + { /* Cleanup items referencing temporary table columns */
<timour> + List_iterator_fast<Item> it(tmp_all_fields3);
<timour> + Item *item;
<timour> + while ((item= it++))
<timour> + item->cleanup();
<timour> + }
<timour> gleb, this is unconditional, however
<timour> looking at how tmp_all_fields3 is used,
<timour> one case that it is initialized inside an IF statement:
<timour> inside
<timour> JOIN::exec()
<timour> {
<timour> ....
<timour> if (curr_join->group || curr_join->tmp_table_param.sum_func_count ||
<timour> (procedure && (procedure->flags & PROC_GROUP)))
<timour> {
<timour> ...
<gleb> timour: looking
<timour> initalize and modify tmp_all_fields3
<timour> ...
<timour> }
<timour> }
<timour> gleb, thus, it makes sense to change your patch as:
<timour> if (tmp_all_fields3 is non-empty)
<timour> {
<timour> cleanup all items in tmp_all_fields3
<timour> }
<timour> gleb, then another question -
<gleb> timour: agree (OTOH isn't this change equivalent to my patch? ;-)
<timour> gleb, not exactly, as with this change we allocate an iterator only if really needed.
<timour> gleb, and it is clearer, otherwise why cleanup something that shouldn't be cleaned up.
<timour> gleb, then naturally, I would like you to investigate how do we cleanup the contents of
<timour> tmp_all_fields[1,2]
<gleb> timour: FYI: cleanup of tmp_all_fields2 like tmp_all_fields3 is probably ok, but tmp_all_fields1 is not (I'm just running tests and looking at gdb traces)
<timour> gleb, could be - my point was that we should not wait for the next similar bug if there are other similar cases.
<timour> gleb, also, please add a comment why tmp_all_fields[2,3] can be cleaned up, but tmp_all_fields1 cannot.
<gleb> timour: I see. but additional investigation is not trivial (need some more time)
<gleb> timour: ok
<timour> gleb, if tmp_all_fields2 needs cleanup, could you add a test.
<gleb> timour: I think I can
[30 Apr 2009 8:36]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/73090 2722 Gleb Shchepa 2009-04-30 Bug #37362: Crash in do_field_eq EXPLAIN EXTENDED of nested query containing a error: 1054 Unknown column '...' in 'field list' may cause a server crash. Parse error like described above forces a call to JOIN::destroy() on malformed subquery. That JOIN::destroy function closes and frees temporary tables. However, temporary fields of these tables may be listed in st_select_lex::group_list of outer query, and that st_select_lex may not cleanup them properly. So, after the JOIN::destroy call that st_select_lex::group_list may have Item_field objects with dangling pointers to freed temporary table Field objects. That caused a crash. @ mysql-test/r/subselect3.result Added test case for bug #37362. @ mysql-test/t/subselect3.test Added test case for bug #37362. @ sql/sql_select.cc Bug #37362: Crash in do_field_eq The JOIN::destroy function has been modified to cleanup temporary table column items.
[28 May 2009 7:40]
Bugs System
Pushed into 5.0.83 (revid:joro@sun.com-20090528073529-q9b8s60vlpu28fny) (version source revid:gshchepa@mysql.com-20090430192037-9p1etcynkglte2j3) (merge vers: 5.0.82) (pib:6)
[28 May 2009 8:13]
Bugs System
Pushed into 5.1.36 (revid:joro@sun.com-20090528073639-yohsb4q1jzg7ycws) (version source revid:mats@sun.com-20090511132802-nnkiyb2huih1tklz) (merge vers: 5.1.35) (pib:6)
[30 May 2009 2:35]
Paul DuBois
Noted in 5.0.83, 5.1.36 changelogs. If a query was such as to produce the error "1054 Unknown column '...' in 'field list'," using EXPLAIN EXTENDED with the query could cause a server crash. Setting report to NDI pending push into 6.0.x.
[3 Aug 2009 23:05]
Paul DuBois
Noted in 5.4.4 changelog.
[10 Aug 2009 17:53]
Paul DuBois
Noted in 5.0.82sp1 changelog.
[10 Aug 2009 18:59]
Bugs System
Pushed into 5.0.85 (revid:build@mysql.com-20090810185326-yr4orhpwq09e3y50) (version source revid:build@mysql.com-20090810185326-yr4orhpwq09e3y50) (merge vers: 5.0.85) (pib:11)
[12 Aug 2009 22:54]
Paul DuBois
Noted in 5.4.2 changelog because next 5.4 version will be 5.4.2 and not 5.4.4.
[15 Aug 2009 2:11]
Paul DuBois
Ignore previous comment about 5.4.2.
[25 Aug 2009 9:23]
Bugs System
Pushed into 5.1.39 (revid:jperkin@sun.com-20090824091334-6ktgrhq218vl7zq1) (version source revid:joerg@mysql.com-20090813203300-nnskc3aofxydzi85) (merge vers: 5.1.39) (pib:11)
[26 Aug 2009 13:45]
Bugs System
Pushed into 5.1.37-ndb-7.0.8 (revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[26 Aug 2009 13:46]
Bugs System
Pushed into 5.1.37-ndb-6.3.27 (revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (version source revid:jonas@mysql.com-20090826105955-bkj027t47gfbamnc) (merge vers: 5.1.37-ndb-6.3.27) (pib:11)
[26 Aug 2009 13:48]
Bugs System
Pushed into 5.1.37-ndb-6.2.19 (revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (version source revid:jonas@mysql.com-20090825194404-37rtosk049t9koc4) (merge vers: 5.1.37-ndb-6.2.19) (pib:11)
[27 Aug 2009 16:32]
Bugs System
Pushed into 5.1.35-ndb-7.1.0 (revid:magnus.blaudd@sun.com-20090827163030-6o3kk6r2oua159hr) (version source revid:jonas@mysql.com-20090826132541-yablppc59e3yb54l) (merge vers: 5.1.37-ndb-7.0.8) (pib:11)
[14 Sep 2009 16:02]
Bugs System
Pushed into 5.4.4-alpha (revid:alik@sun.com-20090914155317-m1g9wodmndzdj4l1) (version source revid:alik@sun.com-20090914155317-m1g9wodmndzdj4l1) (merge vers: 5.4.4-alpha) (pib:11)
[1 Oct 2009 5:58]
Bugs System
Pushed into 5.1.39-ndb-6.3.28 (revid:jonas@mysql.com-20091001055605-ap2kiaarr7p40mmv) (version source revid:jonas@mysql.com-20091001055605-ap2kiaarr7p40mmv) (merge vers: 5.1.39-ndb-6.3.28) (pib:11)
[1 Oct 2009 7:25]
Bugs System
Pushed into 5.1.39-ndb-7.0.9 (revid:jonas@mysql.com-20091001072547-kv17uu06hfjhgjay) (version source revid:jonas@mysql.com-20091001071652-irejtnumzbpsbgk2) (merge vers: 5.1.39-ndb-7.0.9) (pib:11)
[1 Oct 2009 13:25]
Bugs System
Pushed into 5.1.39-ndb-7.1.0 (revid:jonas@mysql.com-20091001123013-g9ob2tsyctpw6zs0) (version source revid:jonas@mysql.com-20091001123013-g9ob2tsyctpw6zs0) (merge vers: 5.1.39-ndb-7.1.0) (pib:11)
[5 Oct 2009 10:50]
Bugs System
Pushed into 5.1.39-ndb-6.2.19 (revid:jonas@mysql.com-20091005103850-dwij2dojwpvf5hi6) (version source revid:jonas@mysql.com-20090930185117-bhud4ek1y0hsj1nv) (merge vers: 5.1.39-ndb-6.2.19) (pib:11)
[8 Oct 2009 20:13]
Paul DuBois
The 5.4 fix has been pushed to 5.4.2.
Description: When running EXPLAIN EXTENDED, mysql crashed as follows: #0 0x00110416 in __kernel_vsyscall () #1 0x00581c78 in pthread_kill () from /lib/libpthread.so.0 #2 0x0843eda3 in write_core (sig=11) at stacktrace.c:302 #3 0x0829b228 in handle_segfault (sig=11) at mysqld.cc:2626 #4 <signal handler called> #5 0x00432f61 in memcpy () from /lib/libc.so.6 #6 0x083f851d in do_field_eq (copy=0xae80d44) at field_conv.cc:32 #7 0x0830e542 in copy_fields (param=0xaf5fbbc) at sql_select.cc:17642 #8 0x083103c6 in end_send_group (join=0xaf5e968, join_tab=0x0, end_of_records=false) at sql_select.cc:14563 #9 0x08322c1c in do_select (join=0xaf5e968, fields=0xaf5fcc4, table=0x0, procedure=0x0) at sql_select.cc:13069 #10 0x08335655 in JOIN::exec (this=0xaf5e968) at sql_select.cc:2740 #11 0x0824f73b in subselect_single_select_engine::exec (this=0xaf73830) at item_subselect.cc:2277 #12 0x0824c10e in Item_subselect::exec (this=0xaf73790) at item_subselect.cc:280 #13 0x0824cf8b in Item_singlerow_subselect::val_int (this=0xaf73790) at item_subselect.cc:629 #14 0x081ddb06 in Item::save_in_field (this=0xaf73790, field=0xaf233a0, no_conversions=false) at item.cc:4886 #15 0x082e7765 in fill_record (thd=0xa9c09c90, ptr=0xae49dec, values=@0xae800fc, ignore_errors=true) at sql_base.cc:8061 #16 0x0843e1e9 in select_union::send_data (this=0xaf74728, values=@0xae800fc) at sql_union.cc:60 #17 0x08309a48 in end_send (join=0xafcc100, join_tab=0xaf5ff0c, end_of_records=false) at sql_select.cc:14406 #18 0x08315b79 in evaluate_join_record (join=0xafcc100, join_tab=0xaf5fd58, error=0) at sql_select.cc:13568 #19 0x08315da5 in sub_select (join=0xafcc100, join_tab=0xaf5fd58, end_of_records=false) at sql_select.cc:13342 #20 0x08322d70 in do_select (join=0xafcc100, fields=0xae800fc, table=0x0, procedure=0x0) at sql_select.cc:13092 #21 0x08335655 in JOIN::exec (this=0xae7edb8) at sql_select.cc:2740 #22 0x083308f2 in mysql_select (thd=0xa9c09c90, rref_pointer_array=0xaf1437c, tables=0xaf73990, wild_num=0, fields=@0xaf1430c, conds=0xaf73ca0, og_num=1, order=0x0, group=0xaf73e38, having=0x0, proc_param=0x0, select_options=2417773056, result=0xaf74728, unit=0xaf14410, select_lex=0xaf14278) at sql_select.cc:2929 #23 0x0843e6f8 in mysql_derived_filling (thd=0xa9c09c90, lex=0xa9c0ad60, orig_table_list=0xaf74138) at sql_derived.cc:264 #24 0x0843e4a3 in mysql_handle_derived (lex=0xa9c0ad60, processor=0x843e528 <mysql_derived_filling(THD*, st_lex*, TABLE_LIST*)>) at sql_derived.cc:56 #25 0x082f890f in open_and_lock_tables_derived (thd=0xa9c09c90, tables=0xaf74138, derived=true) at sql_base.cc:4929 #26 0x082b7921 in open_and_lock_tables (thd=0xa9c09c90, tables=0xaf74138) at mysql_priv.h:1606 #27 0x082aa403 in execute_sqlcom_select (thd=0xa9c09c90, all_tables=0xaf74138) at sql_parse.cc:4789 #28 0x082ac0c9 in mysql_execute_command (thd=0xa9c09c90) at sql_parse.cc:2018 #29 0x082b4ec6 in mysql_parse (thd=0xa9c09c90, inBuf=0xaf13cc0 "EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG( int_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey LIMIT 20 ) AS X WHERE X . int_nokey < 83 GROUP"..., length=317, found_semicolon=0xa9bff260) at sql_parse.cc:5782 #30 0x082b590f in dispatch_command (command=COM_QUERY, thd=0xa9c09c90, packet=0xa9c0b689 "EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG( int_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey LIMIT 20 ) AS X WHERE X . int_nokey < 83 GROUP"..., packet_length=319) at sql_parse.cc:1059 #31 0x082b6b75 in do_command (thd=0xa9c09c90) at sql_parse.cc:732 #32 0x082a4385 in handle_one_connection (arg=0xa9c09c90) at sql_connect.cc:1134 #33 0x0057d32f in start_thread () from /lib/libpthread.so.0 #34 0x0049a27e in clone () from /lib/libc.so.6 The query in question was: EXPLAIN EXTENDED SELECT int_key FROM ( SELECT ( SELECT COUNT( pk ) FROM ( SELECT AVG( int_nokey ) FROM D AS X WHERE X . int_key < 76 ORDER BY int_nokey LIMIT 20 ) AS X WHERE X . int_nokey < 83 GROUP BY int_key LIMIT 1 ) FROM D AS X WHERE X . int_key < 11 GROUP BY int_nokey LIMIT 20 ) AS X WHERE X . int_nokey < 75 How to repeat: A simplifed test case and data will follow shortly.