[MDEV-18512] using DATETIME(6) as row_start/row_end crashes server Created: 2019-02-08  Updated: 2019-05-20  Resolved: 2019-05-20

Status: Closed
Project: MariaDB Server
Component/s: Versioned Tables
Affects Version/s: 10.3, 10.4
Fix Version/s: 10.3.16, 10.4.5

Type: Bug Priority: Major
Reporter: Eugene Kosov (Inactive) Assignee: Alexander Barkov
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-17448 Support DATETIME(6) for ROW START, RO... Open

 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

 Comments   
Comment by Eugene Kosov (Inactive) [ 2019-02-21 ]

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.

Comment by Elena Stepanova [ 2019-03-08 ]

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

Comment by Eugene Kosov (Inactive) [ 2019-03-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?

Comment by Elena Stepanova [ 2019-03-11 ]

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

Comment by Alexander Barkov [ 2019-05-20 ]

Reviewed and merged to 10.3

Generated at Thu Feb 08 08:44:40 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.