Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-23562

Assertion `time_type == MYSQL_TIMESTAMP_DATETIME' failed upon SELECT from versioned table

    XMLWordPrintable

    Details

      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
      

        Attachments

          Activity

            People

            Assignee:
            bar Alexander Barkov
            Reporter:
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: