Hi Sergei, Please review MDEV-10124 Thanks. Here's the story of the related code: 1. The original patch from Wax commit: 0b505fb437eedd1b31c99888247c2259539c095b date: Tue Mar 18 03:07:40 2003 opt_gorder_clause reused the regular order_clause, which already had some protection against ROLLUP queries: order_clause: ORDER_SYM BY { LEX *lex=Lex; if (lex->current_select->linkage != GLOBAL_OPTIONS_TYPE && lex->current_select->select_lex()->olap != UNSPECIFIED_OLAP_TYPE) { net_printf(lex->thd, ER_WRONG_USAGE, "CUBE/ROLLUP", "ORDER BY"); YYABORT; } } order_list; The assumption that ORDER BY in group_concat() had to have the same ROLLUP restriction (with order_clause) was wrong. Moreover, GROUP_CONCAT() in select_item_list was not affected by this restriction, because WITH ROLLUP goes after select_item_list and therefore sel->olap is always equal to UNSPECIFIED_OLAP_TYPE during select_item_list. GROUP BY was not affected: - it goes before WITH ROLLUP and sel->olap is still UNSPECIFIED_OLAP_TYPE - Aggregate functions like AVG(), GROUP_CONCAT() in GROUP BY are not allowed So only GROUP_CONCAT() in HAVING and ORDER BY clauses were erroneously affected by this restriction. 2. Bug#27848 rollup in union part causes error with order of union commit: 3f6073ae63f9cb738cb6f0a6a8136e1d21ba0e1b Author: unknown 2007-12-15 01:42:46 The condition in the ROLLUP protection code became more complex. Note, opt_gconcat_order still reuses the regular order_clause. 3. Bug#16347426 ASSERTION FAILED: (SELECT_INSERT && !TABLES->NEXT_NAME_RESOLUTION_TABLE) || !TAB commit: 2d83663380f5c0ea720e31f51898912b0006cd9f author: Chaithra Gopalareddy date: 2013-04-14 06:00:49 opt_gorder_clause was refactored not to use order_clause and collect information directly to select->gorder_list. The ROLLUP protection code was duplicated from order_clause to the new version of opt_gorder_clause.