Sergei Golubchik added a comment - 2016-01-24 16:41 - edited What happens here: a large table (1*10 6 rows) main.c prepares a simple SELECT columns FROM table and executes it with the CURSOR_TYPE_READ_ONLY flag on the server this goes to mysql_open_cursor() that creates a Select_materialize object Select_materialize::send_result_set_metadata() invokes create_result_table() with keep_row_order=TRUE before my commit (referenced above) keep_row_order caused Aria tables to be created with the DYNAMIC record format with the google encryption patch Aria can preserve the row order in the BLOCK format too so now all temporary tables use BLOCK format to avoid leaking unencrypted data to disk (and BLOCK is faster anyway) in the debug build that query hits an assert in allocate_head() function in ma_bitmap.c : if (insert_order) { uint last_insert_page= share->last_insert_page; uint byte= 6 * (last_insert_page / 16); first_pattern= last_insert_page % 16; DBUG_ASSERT(data + byte < end); data+= byte; }

Michael Widenius added a comment - 2016-01-27 16:35 roblem was that insert-order (enforced by the optimizer) did not handle the case where the bitmap changed to a new one. Fixed by remembering the last bitmap page used and to force usage of this when inserting new rows

Michael Widenius added a comment - 2016-01-27 16:42 Fix pushed