[MDEV-23562] Assertion `time_type == MYSQL_TIMESTAMP_DATETIME' failed upon SELECT from versioned table Created: 2020-08-24  Updated: 2020-12-07  Resolved: 2020-08-24

Status: Closed
Project: MariaDB Server
Component/s: Temporal Types, Versioned Tables
Affects Version/s: 10.4
Fix Version/s: 10.4.16, 10.5.8

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Alexander Barkov
Resolution: Fixed Votes: 0
Labels: affects-tests, regression


 Description   

CREATE TABLE t1 (a INT) WITH SYSTEM VERSIONING;
SET system_versioning_asof = DATE(NOW());
SELECT * from t1;
 
# Cleanup
DROP TABLE t1;

10.4 056766c042

mysqld: /data/src/10.4-bug/sql/sql_type.h:2104: bool Datetime::is_valid_datetime_slow() const: Assertion `time_type == MYSQL_TIMESTAMP_DATETIME' failed.
200824 17:47:42 [ERROR] mysqld got signal 6 ;
 
#7  0x00007fd4e8263f12 in __GI___assert_fail (assertion=0x55de073703b0 "time_type == MYSQL_TIMESTAMP_DATETIME", file=0x55de07370350 "/data/src/10.4-bug/sql/sql_type.h", line=2104, function=0x55de07370880 <Datetime::is_valid_datetime_slow() const::__PRETTY_FUNCTION__> "bool Datetime::is_valid_datetime_slow() const") at assert.c:101
#8  0x000055de0657c01a in Datetime::is_valid_datetime_slow (this=0x7fd4e240c2f0) at /data/src/10.4-bug/sql/sql_type.h:2104
#9  0x000055de06736624 in Datetime::Datetime (this=0x7fd4e240c2f0, from=0x7fd4d0001610) at /data/src/10.4-bug/sql/sql_type.h:2256
#10 0x000055de066e3507 in vers_select_conds_t::init_from_sysvar (this=0x7fd4d0013de0, thd=0x7fd4d0000af0) at /data/src/10.4-bug/sql/sql_select.cc:725
#11 0x000055de066e530e in st_select_lex::vers_setup_conds (this=0x7fd4d0013220, thd=0x7fd4d0000af0, tables=0x7fd4d00137e0) at /data/src/10.4-bug/sql/sql_select.cc:1032
#12 0x000055de066e5a82 in JOIN::prepare (this=0x7fd4d0014848, tables_init=0x7fd4d00137e0, wild_num=1, conds_init=0x0, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x7fd4d0013220, unit_arg=0x7fd4d0004a18) at /data/src/10.4-bug/sql/sql_select.cc:1180
#13 0x000055de066f2ba9 in mysql_select (thd=0x7fd4d0000af0, tables=0x7fd4d00137e0, wild_num=1, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7fd4d0014820, unit=0x7fd4d0004a18, select_lex=0x7fd4d0013220) at /data/src/10.4-bug/sql/sql_select.cc:4653
#14 0x000055de066e27ae in handle_select (thd=0x7fd4d0000af0, lex=0x7fd4d0004958, result=0x7fd4d0014820, setup_tables_done_option=0) at /data/src/10.4-bug/sql/sql_select.cc:422
#15 0x000055de066a8fce in execute_sqlcom_select (thd=0x7fd4d0000af0, all_tables=0x7fd4d00137e0) at /data/src/10.4-bug/sql/sql_parse.cc:6355
#16 0x000055de0669f605 in mysql_execute_command (thd=0x7fd4d0000af0) at /data/src/10.4-bug/sql/sql_parse.cc:3889
#17 0x000055de066acf7b in mysql_parse (thd=0x7fd4d0000af0, rawbuf=0x7fd4d0013198 "SELECT * from t1", length=16, parser_state=0x7fd4e240d570, is_com_multi=false, is_next_command=false) at /data/src/10.4-bug/sql/sql_parse.cc:7896
#18 0x000055de066994b0 in dispatch_command (command=COM_QUERY, thd=0x7fd4d0000af0, packet=0x7fd4d01364d1 "SELECT * from t1", packet_length=16, is_com_multi=false, is_next_command=false) at /data/src/10.4-bug/sql/sql_parse.cc:1835
#19 0x000055de06697c52 in do_command (thd=0x7fd4d0000af0) at /data/src/10.4-bug/sql/sql_parse.cc:1353
#20 0x000055de06821b32 in do_handle_one_connection (connect=0x55de09b8ac60) at /data/src/10.4-bug/sql/sql_connect.cc:1412
#21 0x000055de06821881 in handle_one_connection (arg=0x55de09b8ac60) at /data/src/10.4-bug/sql/sql_connect.cc:1316
#22 0x000055de07225ce7 in pfs_spawn_thread (arg=0x55de09ba67e0) at /data/src/10.4-bug/storage/perfschema/pfs.cc:1869
#23 0x00007fd4ea1ec4a4 in start_thread (arg=0x7fd4e240e700) at pthread_create.c:456
#24 0x00007fd4e8320d0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97

The failure started happening on 10.4 tree after this commit:

commit 04ce29354b6053f0334ad1b8d5acaa0974b10fd8
Author: Alexander Barkov
Date:   Mon Aug 24 09:17:47 2020 +0400
 
    MDEV-23551 Performance degratation in temporal literals in 10.4



 Comments   
Comment by Alexander Barkov [ 2020-12-07 ]

commit 329301d2e647db099e1554663578f0352125d1c9
Author: Alexander Barkov <bar@mariadb.com>
Date:   Mon Aug 24 22:55:39 2020 +0400
 
    MDEV-23562 Assertion `time_type == MYSQL_TIMESTAMP_DATETIME' failed upon SELECT from versioned table
    
    The code in vers_select_conds_t::init_from_sysvar() assumed that
    the value of the system_versioning_asof is DATETIME.
    But it also could be DATE after a query like this:
      SET system_versioning_asof = DATE(NOW());
    
    Fixing Sys_var_vers_asof::update() to convert the value
    of the assignment source to DATETIME if it returned DATE.
    
    Now vers_select_conds_t::init_from_sysvar() always gets a DATETIME value.

Generated at Thu Feb 08 09:23:20 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.