The following code results into a wrong result in MariaDB must of the time. It is not completely deterministic, but about 80% of all executions trigger a wrong execution:
CREATESCHEMA A;
CREATETABLE A.A (A INTEGER, E BIGINT);
INSERTINTO A.A VALUES (4, -2), (3, -1);
SELECT RANK() OVER (ORDERBY D.C) = RANK() OVER (ORDERBY B.A) FROM (SELECT 5 AS C FROM A.A) AS D, (SELECT A.E AS A FROM A.A) AS B;
MariaDB returns 0, 0, 0, 1. Postgres and MySQL both return 0, 0, 1, 1, which is - manually verified - the correct answer. Therefore, I expect that MariaDB should also return this.
We need both RANK window function calls and the equal - erasing one of the RANKs with the equal returns the correct results.
I checked versions 10.4.5 and 10.4.6, I don't know if the bug occurs in previous versions. In MySQL, the query works.
Attachments
Issue Links
relates to
MDEV-19680Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index) || (!(ptr >= table->record[0] && ptr < table->record[0] + table->s->reclength)))' or alike failed upon SELECT with mix of functions from simple view
Stalled
MDEV-20922Adding an order by changes the query results
#8 0x00005582d7e685d3 in Field_long::val_int (this=0x7faebc0751f8) at /10.2/sql/field.cc:4332
#9 0x00005582d7eba603 in Item_ref::val_int_result (this=0x7faebc0150e0) at /10.2/sql/item.cc:7887
#10 0x00005582d7e8bc77 in Type_handler_int_result::make_sort_key (this=0x5582d91ace18 <type_handler_longlong>, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", item=0x7faebc0150e0, sort_field=0x7faebc0176e0, param=0x7faf000f1710) at /10.2/sql/filesort.cc:1070
#11 0x00005582d7b4be2b in Item::make_sort_key (this=0x7faebc0150e0, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", item=0x7faebc0150e0, sort_field=0x7faebc0176e0, param=0x7faf000f1710) at /10.2/sql/item.h:934
#12 0x00005582d7e8c15d in make_sortkey (param=0x7faf000f1710, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", ref_pos=0x7faebc0753e0 "\200E\003\274\256\177") at /10.2/sql/filesort.cc:1187
#13 0x00005582d7e8b321 in find_all_keys (thd=0x7faebc000b00, param=0x7faf000f1710, select=0x0, fs_info=0x7faebc075f60, buffpek_pointers=0x7faf000f1910, tempfile=0x7faf000f17a0, pq=0x0, found_rows=0x7faebc076140) at /10.2/sql/filesort.cc:862
#14 0x00005582d7e895ce in filesort (thd=0x7faebc000b00, table=0x7faebc08bdf8, filesort=0x7faebc016f70, tracker=0x7faebc017138, join=0x7faebc014338, first_table_bit=1) at /10.2/sql/filesort.cc:279
#15 0x00005582d7c89a48 in create_sort_index (thd=0x7faebc000b00, join=0x7faebc014338, tab=0x7faebc0161a8, fsort=0x7faebc016f70) at /10.2/sql/sql_select.cc:22022
#16 0x00005582d7de018a in Window_funcs_sort::exec (this=0x7faebc016ea8, join=0x7faebc014338, keep_filesort_result=true) at /10.2/sql/sql_window.cc:2804
#17 0x00005582d7de06d2 in Window_funcs_computation::exec (this=0x7faebc016e88, join=0x7faebc014338, keep_last_filesort_result=true) at /10.2/sql/sql_window.cc:2936
#18 0x00005582d7c96ba6 in AGGR_OP::end_send (this=0x7faebc016e58) at /10.2/sql/sql_select.cc:26794
#19 0x00005582d7c8189d in sub_select_postjoin_aggr (join=0x7faebc014338, join_tab=0x7faebc0161a8, end_of_records=true) at /10.2/sql/sql_select.cc:18537
#20 0x00005582d7c81bc1 in sub_select (join=0x7faebc014338, join_tab=0x7faebc015df8, end_of_records=true) at /10.2/sql/sql_select.cc:18773
#21 0x00005582d7c813d9 in do_select (join=0x7faebc014338, procedure=0x0) at /10.2/sql/sql_select.cc:18368
#22 0x00005582d7c5b0ad in JOIN::exec_inner (this=0x7faebc014338) at /10.2/sql/sql_select.cc:3626
#23 0x00005582d7c5a55c in JOIN::exec (this=0x7faebc014338) at /10.2/sql/sql_select.cc:3421
#24 0x00005582d7c5b71e in mysql_select (thd=0x7faebc000b00, tables=0x7faebc013c30, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7faebc014318, unit=0x7faebc004700, select_lex=0x7faebc004e38) at /10.2/sql/sql_select.cc:3821
#25 0x00005582d7c4f980 in handle_select (thd=0x7faebc000b00, lex=0x7faebc004638, result=0x7faebc014318, setup_tables_done_option=0) at /10.2/sql/sql_select.cc:377
#26 0x00005582d7c1b056 in execute_sqlcom_select (thd=0x7faebc000b00, all_tables=0x7faebc013c30) at /10.2/sql/sql_parse.cc:6226
#27 0x00005582d7c11a46 in mysql_execute_command (thd=0x7faebc000b00) at /10.2/sql/sql_parse.cc:3533
#28 0x00005582d7c1eee1 in mysql_parse (thd=0x7faebc000b00, rawbuf=0x7faebc012458 "select rank() over (order by c) from (select 5 as c from t1) as dt", length=67, parser_state=0x7faf000f3080, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:7760
#29 0x00005582d7c0d1aa in dispatch_command (command=COM_QUERY, thd=0x7faebc000b00, packet=0x7faebc0962c1 "", packet_length=67, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:1832
#30 0x00005582d7c0babe in do_command (thd=0x7faebc000b00) at /10.2/sql/sql_parse.cc:1386
#31 0x00005582d7d60b0d in do_handle_one_connection (connect=0x5582dba99360) at /10.2/sql/sql_connect.cc:1336
#32 0x00005582d7d60878 in handle_one_connection (arg=0x5582dba99360) at /10.2/sql/sql_connect.cc:1241
#33 0x00005582d858ad94 in pfs_spawn_thread (arg=0x5582dbaa4150) at /10.2/storage/perfschema/pfs.cc:1862
#34 0x00007faf0e4f76ba in start_thread (arg=0x7faf000f4700) at pthread_create.c:333
#35 0x00007faf0d98c41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
on 10.4 assertion was renamed to `marked_for_read()'
Alice Sherepa
added a comment - Thanks a lot for the report!
Reproduced as described on 10.2-10.4:
create table t1 (a int , b int );
insert into t1 values (4, -2), (3, -1);
select b, rank() over ( order by c) , rank() over ( order by dt1.b)
from
( select 5 as c from t1) as dt,
( select b from t1) as dt1;
select b, rank() over ( order by c) , rank() over ( order by dt1.b),
rank() over ( order by c) = rank() over ( order by dt1.b)
from
( select 5 as c from t1) as dt,
( select b from t1) as dt1;
on non-debug versions - wrong results:
10.2.24
MariaDB [test]> select b, rank() over (order by c) , rank() over (order by dt1.b)
-> from
-> (select 5 as c from t1) as dt,
-> (select b from t1) as dt1;
+------+--------------------------+------------------------------+
| b | rank() over (order by c) | rank() over (order by dt1.b) |
+------+--------------------------+------------------------------+
| -2 | 1 | 1 |
| -2 | 1 | 1 |
| -1 | 1 | 3 |
| -1 | 1 | 3 |
+------+--------------------------+------------------------------+
4 rows in set (0.00 sec)
MariaDB [test]> select b, rank() over (order by c) , rank() over (order by dt1.b),
-> rank() over (order by c) = rank() over (order by dt1.b)
-> from
-> (select 5 as c from t1) as dt,
-> (select b from t1) as dt1;
+------+--------------------------+------------------------------+---------------------------------------------------------+
| b | rank() over (order by c) | rank() over (order by dt1.b) | rank() over (order by c) = rank() over (order by dt1.b) |
+------+--------------------------+------------------------------+---------------------------------------------------------+
| -1 | 1 | 1 | 1 |
| -2 | 1 | 2 | 0 |
| -2 | 1 | 2 | 0 |
| -1 | 1 | 4 | 0 |
+------+--------------------------+------------------------------+---------------------------------------------------------+
4 rows in set (0.00 sec)
On debug version with MyIsam and Innodb:
Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index) || (!(ptr >= table->record[0] && ptr < table->record[0] + table->s->reclength)))' fails in Field_long::val_int()
after the query:
select rank() over ( order by c) from ( select 5 as c from t1) as dt;
10.2 64900e3d7c3e5f3639cb
#6 0x00007faf0d8b2bd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x5582d8769e40 "!table || (!table->read_set || bitmap_is_set(table->read_set, field_index) || (!(ptr >= table->record[0] && ptr < table->record[0] + table->s->reclength)))", file=file@entry=0x5582d8769bd8 "/10.2/sql/field.cc", line=line@entry=4332, function=function@entry=0x5582d876c900 <Field_long::val_int()::__PRETTY_FUNCTION__> "virtual longlong Field_long::val_int()") at assert.c:92
#7 0x00007faf0d8b2c82 in __GI___assert_fail (assertion=0x5582d8769e40 "!table || (!table->read_set || bitmap_is_set(table->read_set, field_index) || (!(ptr >= table->record[0] && ptr < table->record[0] + table->s->reclength)))", file=0x5582d8769bd8 "/10.2/sql/field.cc", line=4332, function=0x5582d876c900 <Field_long::val_int()::__PRETTY_FUNCTION__> "virtual longlong Field_long::val_int()") at assert.c:101
#8 0x00005582d7e685d3 in Field_long::val_int (this=0x7faebc0751f8) at /10.2/sql/field.cc:4332
#9 0x00005582d7eba603 in Item_ref::val_int_result (this=0x7faebc0150e0) at /10.2/sql/item.cc:7887
#10 0x00005582d7e8bc77 in Type_handler_int_result::make_sort_key (this=0x5582d91ace18 <type_handler_longlong>, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", item=0x7faebc0150e0, sort_field=0x7faebc0176e0, param=0x7faf000f1710) at /10.2/sql/filesort.cc:1070
#11 0x00005582d7b4be2b in Item::make_sort_key (this=0x7faebc0150e0, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", item=0x7faebc0150e0, sort_field=0x7faebc0176e0, param=0x7faf000f1710) at /10.2/sql/item.h:934
#12 0x00005582d7e8c15d in make_sortkey (param=0x7faf000f1710, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", ref_pos=0x7faebc0753e0 "\200E\003\274\256\177") at /10.2/sql/filesort.cc:1187
#13 0x00005582d7e8b321 in find_all_keys (thd=0x7faebc000b00, param=0x7faf000f1710, select=0x0, fs_info=0x7faebc075f60, buffpek_pointers=0x7faf000f1910, tempfile=0x7faf000f17a0, pq=0x0, found_rows=0x7faebc076140) at /10.2/sql/filesort.cc:862
#14 0x00005582d7e895ce in filesort (thd=0x7faebc000b00, table=0x7faebc08bdf8, filesort=0x7faebc016f70, tracker=0x7faebc017138, join=0x7faebc014338, first_table_bit=1) at /10.2/sql/filesort.cc:279
#15 0x00005582d7c89a48 in create_sort_index (thd=0x7faebc000b00, join=0x7faebc014338, tab=0x7faebc0161a8, fsort=0x7faebc016f70) at /10.2/sql/sql_select.cc:22022
#16 0x00005582d7de018a in Window_funcs_sort::exec (this=0x7faebc016ea8, join=0x7faebc014338, keep_filesort_result=true) at /10.2/sql/sql_window.cc:2804
#17 0x00005582d7de06d2 in Window_funcs_computation::exec (this=0x7faebc016e88, join=0x7faebc014338, keep_last_filesort_result=true) at /10.2/sql/sql_window.cc:2936
#18 0x00005582d7c96ba6 in AGGR_OP::end_send (this=0x7faebc016e58) at /10.2/sql/sql_select.cc:26794
#19 0x00005582d7c8189d in sub_select_postjoin_aggr (join=0x7faebc014338, join_tab=0x7faebc0161a8, end_of_records=true) at /10.2/sql/sql_select.cc:18537
#20 0x00005582d7c81bc1 in sub_select (join=0x7faebc014338, join_tab=0x7faebc015df8, end_of_records=true) at /10.2/sql/sql_select.cc:18773
#21 0x00005582d7c813d9 in do_select (join=0x7faebc014338, procedure=0x0) at /10.2/sql/sql_select.cc:18368
#22 0x00005582d7c5b0ad in JOIN::exec_inner (this=0x7faebc014338) at /10.2/sql/sql_select.cc:3626
#23 0x00005582d7c5a55c in JOIN::exec (this=0x7faebc014338) at /10.2/sql/sql_select.cc:3421
#24 0x00005582d7c5b71e in mysql_select (thd=0x7faebc000b00, tables=0x7faebc013c30, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7faebc014318, unit=0x7faebc004700, select_lex=0x7faebc004e38) at /10.2/sql/sql_select.cc:3821
#25 0x00005582d7c4f980 in handle_select (thd=0x7faebc000b00, lex=0x7faebc004638, result=0x7faebc014318, setup_tables_done_option=0) at /10.2/sql/sql_select.cc:377
#26 0x00005582d7c1b056 in execute_sqlcom_select (thd=0x7faebc000b00, all_tables=0x7faebc013c30) at /10.2/sql/sql_parse.cc:6226
#27 0x00005582d7c11a46 in mysql_execute_command (thd=0x7faebc000b00) at /10.2/sql/sql_parse.cc:3533
#28 0x00005582d7c1eee1 in mysql_parse (thd=0x7faebc000b00, rawbuf=0x7faebc012458 "select rank() over (order by c) from (select 5 as c from t1) as dt", length=67, parser_state=0x7faf000f3080, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:7760
#29 0x00005582d7c0d1aa in dispatch_command (command=COM_QUERY, thd=0x7faebc000b00, packet=0x7faebc0962c1 "", packet_length=67, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:1832
#30 0x00005582d7c0babe in do_command (thd=0x7faebc000b00) at /10.2/sql/sql_parse.cc:1386
#31 0x00005582d7d60b0d in do_handle_one_connection (connect=0x5582dba99360) at /10.2/sql/sql_connect.cc:1336
#32 0x00005582d7d60878 in handle_one_connection (arg=0x5582dba99360) at /10.2/sql/sql_connect.cc:1241
#33 0x00005582d858ad94 in pfs_spawn_thread (arg=0x5582dbaa4150) at /10.2/storage/perfschema/pfs.cc:1862
#34 0x00007faf0e4f76ba in start_thread (arg=0x7faf000f4700) at pthread_create.c:333
#35 0x00007faf0d98c41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
on 10.4 assertion was renamed to `marked_for_read()'
So the field c in the query is actually a constant.
This crashes on an ASSERT because the bitmap read_set of the temp table
is not set for c. The item c is an Item_direct_view_ref, which refers to the constant 5.
For sorting on the temp table, in the function find_all_keys we use the
bitmap tmp_set, initialize it and then call the function register_used_fields
which sets read_set for the fields involved in
sorting (both sort-key and addon fields).
Inside this function when we come across the item c, the bitmap read_set is not
set. There is no need because it is a constant item and for
Item_direct_view_ref we need to get the
value from the original item.
But while running make_sortkey we call val_*_result, which tries to get the
value from the temp table and then hits the assert. For Item_direct_view_ref
items we need to get the value from the original item.
Varun Gupta (Inactive)
added a comment - Simplifying the problematic query:
Using a view
create view v1 as select 5 as c from t1;
select b, rank() over ( order by c) from v1;
So the field c in the query is actually a constant.
This crashes on an ASSERT because the bitmap read_set of the temp table
is not set for c. The item c is an Item_direct_view_ref, which refers to the constant 5.
For sorting on the temp table, in the function find_all_keys we use the
bitmap tmp_set, initialize it and then call the function register_used_fields
which sets read_set for the fields involved in
sorting (both sort-key and addon fields).
Inside this function when we come across the item c, the bitmap read_set is not
set. There is no need because it is a constant item and for
Item_direct_view_ref we need to get the
value from the original item.
But while running make_sortkey we call val_*_result, which tries to get the
value from the temp table and then hits the assert. For Item_direct_view_ref
items we need to get the value from the original item.
So this should also be fixed by MDEV-20922 .
Varun, your example does not work:
mysqltest: At line 4044: query 'select b, rank() over (order by c) from v1' failed: 1054: Unknown column 'b' in 'field list'
Michael Widenius
added a comment - Varun, your example does not work:
mysqltest: At line 4044: query 'select b, rank() over (order by c) from v1' failed: 1054: Unknown column 'b' in 'field list'
The problematic query outlined a bug in window functions sorting
optimization. When multiple window functions are present in a query,
we sort the sorting key (as defined by PARTITION BY and ORDER BY) from
generic to specific.
SELECT RANK() OVER (ORDER BY const_col) as r1,
RANK() OVER (ORDER BY const_col, a) as r2,
RANK() OVER (PARTITION BY c) as r3,
RANK() OVER (PARTITION BY c ORDER BY b) as r4
FROM table;
For these functions, the sorting we need to do for window function
computations are: [(const_col), (const_col, a)] and [(c), (c, b)].
Instead of doing 4 different sort order, the sorts grouped within [] are
compatible and we can use the most specific sort to cover both window
functions.
The bug was caused by an incorrect flagging of which sort is most
specific for a compatible group of functions. In our specific test case,
instead of picking (const_col, a) as the most specific sort, it would
only sort by (const_col), which lead to wrong results for rank function.
By ensuring that we pick the last sort key before an "incompatible sort"
flag is met in our "ordered array of sorting specifications", we
guarantee correct results.
Michael Widenius
added a comment - The problematic query outlined a bug in window functions sorting
optimization. When multiple window functions are present in a query,
we sort the sorting key (as defined by PARTITION BY and ORDER BY) from
generic to specific.
SELECT RANK() OVER (ORDER BY const_col) as r1,
RANK() OVER (ORDER BY const_col, a) as r2,
RANK() OVER (PARTITION BY c) as r3,
RANK() OVER (PARTITION BY c ORDER BY b) as r4
FROM table;
For these functions, the sorting we need to do for window function
computations are: [(const_col), (const_col, a)] and [(c), (c, b)] .
Instead of doing 4 different sort order, the sorts grouped within [] are
compatible and we can use the most specific sort to cover both window
functions.
The bug was caused by an incorrect flagging of which sort is most
specific for a compatible group of functions. In our specific test case,
instead of picking (const_col, a) as the most specific sort, it would
only sort by (const_col), which lead to wrong results for rank function.
By ensuring that we pick the last sort key before an "incompatible sort"
flag is met in our "ordered array of sorting specifications", we
guarantee correct results.
Thanks a lot for the report!
Reproduced as described on 10.2-10.4:
on non-debug versions - wrong results:
10.2.24
MariaDB [test]> select b, rank() over (order by c) , rank() over (order by dt1.b)
-> from
-> (select 5 as c from t1) as dt,
-> (select b from t1) as dt1;
+------+--------------------------+------------------------------+
| b | rank() over (order by c) | rank() over (order by dt1.b) |
+------+--------------------------+------------------------------+
| -2 | 1 | 1 |
| -2 | 1 | 1 |
| -1 | 1 | 3 |
| -1 | 1 | 3 |
+------+--------------------------+------------------------------+
4 rows in set (0.00 sec)
MariaDB [test]> select b, rank() over (order by c) , rank() over (order by dt1.b),
-> rank() over (order by c) = rank() over (order by dt1.b)
-> from
-> (select 5 as c from t1) as dt,
-> (select b from t1) as dt1;
+------+--------------------------+------------------------------+---------------------------------------------------------+
| b | rank() over (order by c) | rank() over (order by dt1.b) | rank() over (order by c) = rank() over (order by dt1.b) |
+------+--------------------------+------------------------------+---------------------------------------------------------+
| -1 | 1 | 1 | 1 |
| -2 | 1 | 2 | 0 |
| -2 | 1 | 2 | 0 |
| -1 | 1 | 4 | 0 |
+------+--------------------------+------------------------------+---------------------------------------------------------+
4 rows in set (0.00 sec)
On debug version with MyIsam and Innodb:
Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index) || (!(ptr >= table->record[0] && ptr < table->record[0] + table->s->reclength)))' fails in Field_long::val_int()
after the query:
10.2 64900e3d7c3e5f3639cb
#6 0x00007faf0d8b2bd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x5582d8769e40 "!table || (!table->read_set || bitmap_is_set(table->read_set, field_index) || (!(ptr >= table->record[0] && ptr < table->record[0] + table->s->reclength)))", file=file@entry=0x5582d8769bd8 "/10.2/sql/field.cc", line=line@entry=4332, function=function@entry=0x5582d876c900 <Field_long::val_int()::__PRETTY_FUNCTION__> "virtual longlong Field_long::val_int()") at assert.c:92
#7 0x00007faf0d8b2c82 in __GI___assert_fail (assertion=0x5582d8769e40 "!table || (!table->read_set || bitmap_is_set(table->read_set, field_index) || (!(ptr >= table->record[0] && ptr < table->record[0] + table->s->reclength)))", file=0x5582d8769bd8 "/10.2/sql/field.cc", line=4332, function=0x5582d876c900 <Field_long::val_int()::__PRETTY_FUNCTION__> "virtual longlong Field_long::val_int()") at assert.c:101
#8 0x00005582d7e685d3 in Field_long::val_int (this=0x7faebc0751f8) at /10.2/sql/field.cc:4332
#9 0x00005582d7eba603 in Item_ref::val_int_result (this=0x7faebc0150e0) at /10.2/sql/item.cc:7887
#10 0x00005582d7e8bc77 in Type_handler_int_result::make_sort_key (this=0x5582d91ace18 <type_handler_longlong>, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", item=0x7faebc0150e0, sort_field=0x7faebc0176e0, param=0x7faf000f1710) at /10.2/sql/filesort.cc:1070
#11 0x00005582d7b4be2b in Item::make_sort_key (this=0x7faebc0150e0, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", item=0x7faebc0150e0, sort_field=0x7faebc0176e0, param=0x7faf000f1710) at /10.2/sql/item.h:934
#12 0x00005582d7e8c15d in make_sortkey (param=0x7faf000f1710, to=0x7faebc00c6a0 '\245' <repeats 192 times>, "h4z\025", ref_pos=0x7faebc0753e0 "\200E\003\274\256\177") at /10.2/sql/filesort.cc:1187
#13 0x00005582d7e8b321 in find_all_keys (thd=0x7faebc000b00, param=0x7faf000f1710, select=0x0, fs_info=0x7faebc075f60, buffpek_pointers=0x7faf000f1910, tempfile=0x7faf000f17a0, pq=0x0, found_rows=0x7faebc076140) at /10.2/sql/filesort.cc:862
#14 0x00005582d7e895ce in filesort (thd=0x7faebc000b00, table=0x7faebc08bdf8, filesort=0x7faebc016f70, tracker=0x7faebc017138, join=0x7faebc014338, first_table_bit=1) at /10.2/sql/filesort.cc:279
#15 0x00005582d7c89a48 in create_sort_index (thd=0x7faebc000b00, join=0x7faebc014338, tab=0x7faebc0161a8, fsort=0x7faebc016f70) at /10.2/sql/sql_select.cc:22022
#16 0x00005582d7de018a in Window_funcs_sort::exec (this=0x7faebc016ea8, join=0x7faebc014338, keep_filesort_result=true) at /10.2/sql/sql_window.cc:2804
#17 0x00005582d7de06d2 in Window_funcs_computation::exec (this=0x7faebc016e88, join=0x7faebc014338, keep_last_filesort_result=true) at /10.2/sql/sql_window.cc:2936
#18 0x00005582d7c96ba6 in AGGR_OP::end_send (this=0x7faebc016e58) at /10.2/sql/sql_select.cc:26794
#19 0x00005582d7c8189d in sub_select_postjoin_aggr (join=0x7faebc014338, join_tab=0x7faebc0161a8, end_of_records=true) at /10.2/sql/sql_select.cc:18537
#20 0x00005582d7c81bc1 in sub_select (join=0x7faebc014338, join_tab=0x7faebc015df8, end_of_records=true) at /10.2/sql/sql_select.cc:18773
#21 0x00005582d7c813d9 in do_select (join=0x7faebc014338, procedure=0x0) at /10.2/sql/sql_select.cc:18368
#22 0x00005582d7c5b0ad in JOIN::exec_inner (this=0x7faebc014338) at /10.2/sql/sql_select.cc:3626
#23 0x00005582d7c5a55c in JOIN::exec (this=0x7faebc014338) at /10.2/sql/sql_select.cc:3421
#24 0x00005582d7c5b71e in mysql_select (thd=0x7faebc000b00, tables=0x7faebc013c30, wild_num=0, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7faebc014318, unit=0x7faebc004700, select_lex=0x7faebc004e38) at /10.2/sql/sql_select.cc:3821
#25 0x00005582d7c4f980 in handle_select (thd=0x7faebc000b00, lex=0x7faebc004638, result=0x7faebc014318, setup_tables_done_option=0) at /10.2/sql/sql_select.cc:377
#26 0x00005582d7c1b056 in execute_sqlcom_select (thd=0x7faebc000b00, all_tables=0x7faebc013c30) at /10.2/sql/sql_parse.cc:6226
#27 0x00005582d7c11a46 in mysql_execute_command (thd=0x7faebc000b00) at /10.2/sql/sql_parse.cc:3533
#28 0x00005582d7c1eee1 in mysql_parse (thd=0x7faebc000b00, rawbuf=0x7faebc012458 "select rank() over (order by c) from (select 5 as c from t1) as dt", length=67, parser_state=0x7faf000f3080, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:7760
#29 0x00005582d7c0d1aa in dispatch_command (command=COM_QUERY, thd=0x7faebc000b00, packet=0x7faebc0962c1 "", packet_length=67, is_com_multi=false, is_next_command=false) at /10.2/sql/sql_parse.cc:1832
#30 0x00005582d7c0babe in do_command (thd=0x7faebc000b00) at /10.2/sql/sql_parse.cc:1386
#31 0x00005582d7d60b0d in do_handle_one_connection (connect=0x5582dba99360) at /10.2/sql/sql_connect.cc:1336
#32 0x00005582d7d60878 in handle_one_connection (arg=0x5582dba99360) at /10.2/sql/sql_connect.cc:1241
#33 0x00005582d858ad94 in pfs_spawn_thread (arg=0x5582dbaa4150) at /10.2/storage/perfschema/pfs.cc:1862
#34 0x00007faf0e4f76ba in start_thread (arg=0x7faf000f4700) at pthread_create.c:333
#35 0x00007faf0d98c41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
on 10.4 assertion was renamed to `marked_for_read()'