[MDEV-18512] using DATETIME(6) as row_start/row_end crashes server - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.3(EOL), 10.4(EOL)
Fix Version/s: 10.3.16, 10.4.5
Component/s: Versioned Tables
Labels:
None

Description

create table t (

  a int,

  row_start datetime(6) generated always as row start,

  row_end datetime(6) generated always as row end,

  period for system_time(row_start, row_end)

) with system versioning;

insert into t (a) values (1);

drop table t;

#8  Field::set_max (this=0x7f92e00fb750) at field.h:654

#9  TABLE::vers_update_fields (this=0x7f92e0036058) at table.cc:7926

#10 fill_record (thd=0x7f92e0000cf8, table_arg=0x7f92e0036058, fields=class List<Item> with 1 elements, values=class List<Item> with 1 elements, ignore_errors=false, update=false) at sql_base.cc:8322

#11 fill_record_n_invoke_before_triggers (thd=0x7f92e0000cf8, table=0x7f92e0036058, fields=class List<Item> with 1 elements, values=class List<Item> with 1 elements, ignore_errors=false, event=TRG_EVENT_INSERT) at sql_base.cc:8449

#12 mysql_insert (thd=0x7f92e0000cf8, table_list=0x7f92e0013ee8, fields=class List<Item> with 1 elements, values_list=..., update_fields=class List<Item> with 0 elements, update_values=class List<Item> with 0 elements, duplic=DUP_ERROR, ignore=false) at sql_insert.cc:960

#13 mysql_execute_command (thd=0x7f92e0000cf8) at sql_parse.cc:4728

#14 mysql_parse (thd=0x7f92e0000cf8, rawbuf=0x7f92e0013e00 "insert into t (a) values (1)", length=28, parser_state=0x7f9335fb9560, is_com_multi=false, is_next_command=false) at sql_parse.cc:8095

row_start/row_end can only be either TIMESTAMP(6) or BIGINT UNSIGNED. DATETIME(6) should be disallowed.

Test case was found here https://stackoverflow.com/questions/52655055/using-datetime-in-mariadb-10-3-9-system-versioned-tables-works-for-rowstart-but

Attachments

Issue Links

relates to

MDEV-17448 Support DATETIME(6) for ROW START, ROW END

Open

Activity

Ascending order - Click to sort in descending order

Eugene Kosov (Inactive) added a comment - 2019-02-21 16:04

I do not remember whether this should be implemented or disabled. I think it should be disabled as there are no test cases for DATETIME.

Eugene Kosov (Inactive) added a comment - 2019-02-21 16:04 I do not remember whether this should be implemented or disabled. I think it should be disabled as there are no test cases for DATETIME .

Elena Stepanova added a comment - 2019-03-08 21:57 - edited

As a fancy side-effect, the failure occurs even when a correct type is used in the statement, but it is executed under SQL_MODE which converts timestamp into datetime:

set sql_mode= 'MAXDB';

create or replace table t1 (a int, s timestamp(6) as row start, e timestamp(6) as row end, period for system_time(s,e)) with system versioning;

show create table t1;

insert into t1 (a) values (1);

10.3 d30f17af
mysqld: /data/src/10.3/sql/field.h:654: virtual void Field::set_max(): Assertion `0' failed.
190308 23:57:12 [ERROR] mysqld got signal 6 ;

#7 0x00007f03d7d06ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8 0x000056037d3a7ea0 in Field::set_max (this=0x7f03c006f738) at /data/src/10.3/sql/field.h:654
#9 0x000056037d1e12ad in TABLE::vers_update_fields (this=0x7f03c0121180) at /data/src/10.3/sql/table.cc:7935
#10 0x000056037d03e52b in fill_record (thd=0x7f03c0000b00, table_arg=0x7f03c0121180, fields=..., values=..., ignore_errors=false, update=false) at /data/src/10.3/sql/sql_base.cc:8322
#11 0x000056037d03e98e in fill_record_n_invoke_before_triggers (thd=0x7f03c0000b00, table=0x7f03c0121180, fields=..., values=..., ignore_errors=false, event=TRG_EVENT_INSERT) at /data/src/10.3/sql/sql_base.cc:8450
#12 0x000056037d081911 in mysql_insert (thd=0x7f03c0000b00, table_list=0x7f03c0014de0, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false) at /data/src/10.3/sql/sql_insert.cc:960
#13 0x000056037d0c39de in mysql_execute_command (thd=0x7f03c0000b00) at /data/src/10.3/sql/sql_parse.cc:4777
#14 0x000056037d0ce73a in mysql_parse (thd=0x7f03c0000b00, rawbuf=0x7f03c0014cf8 "insert into t1 (a) values (1)", length=29, parser_state=0x7f03d1ead5f0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8142
#15 0x000056037d0bb825 in dispatch_command (command=COM_QUERY, thd=0x7f03c0000b00, packet=0x7f03c000b201 "insert into t1 (a) values (1)", packet_length=29, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1854
#16 0x000056037d0ba20f in do_command (thd=0x7f03c0000b00) at /data/src/10.3/sql/sql_parse.cc:1396
#17 0x000056037d222ab5 in do_handle_one_connection (connect=0x560380f7b0f0) at /data/src/10.3/sql/sql_connect.cc:1403
#18 0x000056037d222839 in handle_one_connection (arg=0x560380f7b0f0) at /data/src/10.3/sql/sql_connect.cc:1309
#19 0x000056037d6befdb in pfs_spawn_thread (arg=0x560380ebff60) at /data/src/10.3/storage/perfschema/pfs.cc:1862
#20 0x00007f03d99dd494 in start_thread (arg=0x7f03d1eae700) at pthread_create.c:333
#21 0x00007f03d7dc393f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Elena Stepanova added a comment - 2019-03-08 21:57 - edited As a fancy side-effect, the failure occurs even when a correct type is used in the statement, but it is executed under SQL_MODE which converts timestamp into datetime: set sql_mode= 'MAXDB' ; create or replace table t1 (a int , s timestamp (6) as row start, e timestamp (6) as row end , period for system_time(s,e)) with system versioning; show create table t1; insert into t1 (a) values (1); 10.3 d30f17af mysqld: /data/src/10.3/sql/field.h:654: virtual void Field::set_max(): Assertion `0' failed. 190308 23:57:12 [ERROR] mysqld got signal 6 ; #7 0x00007f03d7d06ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 #8 0x000056037d3a7ea0 in Field::set_max (this=0x7f03c006f738) at /data/src/10.3/sql/field.h:654 #9 0x000056037d1e12ad in TABLE::vers_update_fields (this=0x7f03c0121180) at /data/src/10.3/sql/table.cc:7935 #10 0x000056037d03e52b in fill_record (thd=0x7f03c0000b00, table_arg=0x7f03c0121180, fields=..., values=..., ignore_errors=false, update=false) at /data/src/10.3/sql/sql_base.cc:8322 #11 0x000056037d03e98e in fill_record_n_invoke_before_triggers (thd=0x7f03c0000b00, table=0x7f03c0121180, fields=..., values=..., ignore_errors=false, event=TRG_EVENT_INSERT) at /data/src/10.3/sql/sql_base.cc:8450 #12 0x000056037d081911 in mysql_insert (thd=0x7f03c0000b00, table_list=0x7f03c0014de0, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false) at /data/src/10.3/sql/sql_insert.cc:960 #13 0x000056037d0c39de in mysql_execute_command (thd=0x7f03c0000b00) at /data/src/10.3/sql/sql_parse.cc:4777 #14 0x000056037d0ce73a in mysql_parse (thd=0x7f03c0000b00, rawbuf=0x7f03c0014cf8 "insert into t1 (a) values (1)", length=29, parser_state=0x7f03d1ead5f0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8142 #15 0x000056037d0bb825 in dispatch_command (command=COM_QUERY, thd=0x7f03c0000b00, packet=0x7f03c000b201 "insert into t1 (a) values (1)", packet_length=29, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1854 #16 0x000056037d0ba20f in do_command (thd=0x7f03c0000b00) at /data/src/10.3/sql/sql_parse.cc:1396 #17 0x000056037d222ab5 in do_handle_one_connection (connect=0x560380f7b0f0) at /data/src/10.3/sql/sql_connect.cc:1403 #18 0x000056037d222839 in handle_one_connection (arg=0x560380f7b0f0) at /data/src/10.3/sql/sql_connect.cc:1309 #19 0x000056037d6befdb in pfs_spawn_thread (arg=0x560380ebff60) at /data/src/10.3/storage/perfschema/pfs.cc:1862 #20 0x00007f03d99dd494 in start_thread (arg=0x7f03d1eae700) at pthread_create.c:333 #21 0x00007f03d7dc393f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Eugene Kosov (Inactive) added a comment - 2019-03-11 13:11

This is because when sql_mode= 'MAXDB' TIMESTAMP implicitly becomes DATETIME https://github.com/MariaDB/server/blob/88d89ee0bae24b71416c2af4f4c2f2be7b6a033a/sql/sql_yacc.yy#L6946

Is it known to all sql_mode = 'MAXDB' users? Should error message be fixed for such case?

Eugene Kosov (Inactive) added a comment - 2019-03-11 13:11 This is because when sql_mode= 'MAXDB' TIMESTAMP implicitly becomes DATETIME https://github.com/MariaDB/server/blob/88d89ee0bae24b71416c2af4f4c2f2be7b6a033a/sql/sql_yacc.yy#L6946 Is it known to all sql_mode = 'MAXDB' users? Should error message be fixed for such case?

Elena Stepanova added a comment - 2019-03-11 13:18 - edited

Right, as I said, a side-effect of the SQL_MODE which converts timestamp into datetime. I'm not 100% sure that MAXDB is the only one which features it, but my tests stopped failing after I removed it, so hopefully it is.

I don't know if it's known to the users. I'm not sure if there are any users of MAXDB mode. Anyway, I also created a documentation/deprecation bug: ~~MDEV-18864~~

Elena Stepanova added a comment - 2019-03-11 13:18 - edited Right, as I said, a side-effect of the SQL_MODE which converts timestamp into datetime. I'm not 100% sure that MAXDB is the only one which features it, but my tests stopped failing after I removed it, so hopefully it is. I don't know if it's known to the users. I'm not sure if there are any users of MAXDB mode. Anyway, I also created a documentation/deprecation bug: MDEV-18864

Alexander Barkov added a comment - 2019-05-20 11:39

Reviewed and merged to 10.3

Alexander Barkov added a comment - 2019-05-20 11:39 Reviewed and merged to 10.3

MariaDB Server

using DATETIME(6) as row_start/row_end crashes server

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration