[MDEV-5285] Assertion field->prefix_len ? field->prefix_len == len : templ->mysql_col_len == len fails on crossgrade from 10.0.5 to MySQL 5.6 with TIMESTAMP(N) Created: 2013-11-12  Updated: 2013-11-13  Resolved: 2013-11-13

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.5
Fix Version/s: 10.0.6

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Golubchik
Resolution: Won't Fix Votes: 0
Labels: upgrade


 Description   

After crossgrade from MariaDB 10.0 to MySQL 5.6, SELECT from a table with TIMESTAMP(N) causes an assertion failure.
I don't know if there is anything we can do about it, but since there is a demand on this scenario to work (as mentioned in MDEV-5248, for example), it should be at least investigated.

To reproduce,

  • start MariaDB 10.0.5
  • run 

    DROP TABLE IF EXISTS t1;
    		 
     
    		 
    CREATE TABLE t1 (
    		 
      t1_TIMESTAMP_5 TIMESTAMP(5)
    		 
    ) ENGINE=InnoDB;
    		 
     
    		 
    INSERT INTO t1 VALUES ( '2012-12-21 12:12:12.12121' );

  • stop MariaDB 10.0;
  • start MySQL 5.6 (e.g. 5.6.14), debug binary, on the same datadir;
  • run mysql_upgrade;
  • run SELECT * FROM t1

2013-11-13 00:37:30 7f1d6a00b700  InnoDB: Assertion failure in thread 139764309210880 in file row0sel.cc line 2743
 
InnoDB: Failing assertion: field->prefix_len ? field->prefix_len == len : templ->mysql_col_len == len
 
InnoDB: We intentionally generate a memory trap.
 

#5  0x00007f1d81048b8b in __GI_abort () at abort.c:91
 
#6  0x0000000000c3b705 in row_sel_field_store_in_mysql_format_func (dest=0x7f1d5c0c8891 "", templ=0x7f1d5c092738, index=0x7f1d5c0d2618, field_no=3, data=0x7f1d6fa60090 "P\324", <incomplete sequence \334>, len=7) at mysql-5.6/storage/innobase/row/row0sel.cc:2741
 
#7  0x0000000000c3bcaa in row_sel_store_mysql_field_func (mysql_rec=0x7f1d5c0c8890 "\377", prebuilt=0x7f1d5c02fb38, rec=0x7f1d6fa6007d "", index=0x7f1d5c0d2618, offsets=0x7f1d6a007b70, field_no=3, templ=0x7f1d5c092738) at mysql-5.6/storage/innobase/row/row0sel.cc:2888
 
#8  0x0000000000c3bed4 in row_sel_store_mysql_rec (mysql_rec=0x7f1d5c0c8890 "\377", prebuilt=0x7f1d5c02fb38, rec=0x7f1d6fa6007d "", rec_clust=0, index=0x7f1d5c0d2618, offsets=0x7f1d6a007b70) at mysql-5.6/storage/innobase/row/row0sel.cc:2947
 
#9  0x0000000000c3fa03 in row_search_for_mysql (buf=0x7f1d5c0c8890 "\377", mode=1, prebuilt=0x7f1d5c02fb38, match_mode=0, direction=0) at mysql-5.6/storage/innobase/row/row0sel.cc:4869
 
#10 0x0000000000b21ec9 in ha_innobase::index_read (this=0x7f1d5c052540, buf=0x7f1d5c0c8890 "\377", key_ptr=0x0, key_len=0, find_flag=HA_READ_AFTER_KEY) at mysql-5.6/storage/innobase/handler/ha_innodb.cc:7468
 
#11 0x0000000000b22bd4 in ha_innobase::index_first (this=0x7f1d5c052540, buf=0x7f1d5c0c8890 "\377") at mysql-5.6/storage/innobase/handler/ha_innodb.cc:7835
 
#12 0x0000000000b22dbc in ha_innobase::rnd_next (this=0x7f1d5c052540, buf=0x7f1d5c0c8890 "\377") at mysql-5.6/storage/innobase/handler/ha_innodb.cc:7932
 
#13 0x000000000063f524 in handler::ha_rnd_next (this=0x7f1d5c052540, buf=0x7f1d5c0c8890 "\377") at mysql-5.6/sql/handler.cc:2638
 
#14 0x000000000098c88e in rr_sequential (info=0x7f1d5c0068e0) at mysql-5.6/sql/records.cc:478
 
#15 0x00000000007ae535 in join_init_read_record (tab=0x7f1d5c006850) at mysql-5.6/sql/sql_executor.cc:2392
 
#16 0x00000000007abcd9 in sub_select (join=0x7f1d5c005a70, join_tab=0x7f1d5c006850, end_of_records=false) at mysql-5.6/sql/sql_executor.cc:1253
 
#17 0x00000000007ab6e1 in do_select (join=0x7f1d5c005a70) at mysql-5.6/sql/sql_executor.cc:930
 
#18 0x00000000007a9602 in JOIN::exec (this=0x7f1d5c005a70) at mysql-5.6/sql/sql_executor.cc:191
 
#19 0x000000000080b26e in mysql_execute_select (thd=0x3972a90, select_lex=0x3975398, free_join=true) at mysql-5.6/sql/sql_select.cc:1100
 
#20 0x000000000080b56b in mysql_select (thd=0x3972a90, tables=0x7f1d5c005430, wild_num=1, fields=..., conds=0x0, order=0x3975560, group=0x3975498, having=0x0, select_options=2147748608, result=0x7f1d5c005a48, unit=0x3974d50, select_lex=0x3975398) at mysql-5.6/sql/sql_select.cc:1221
 
#21 0x00000000008095a6 in handle_select (thd=0x3972a90, result=0x7f1d5c005a48, setup_tables_done_option=0) at mysql-5.6/sql/sql_select.cc:110
 
#22 0x00000000007e30b9 in execute_sqlcom_select (thd=0x3972a90, all_tables=0x7f1d5c005430) at mysql-5.6/sql/sql_parse.cc:5094
 
#23 0x00000000007dbb66 in mysql_execute_command (thd=0x3972a90) at mysql-5.6/sql/sql_parse.cc:2642
 
#24 0x00000000007e5812 in mysql_parse (thd=0x3972a90, rawbuf=0x7f1d5c005240 "select * from t1", length=16, parser_state=0x7f1d6a00a120) at mysql-5.6/sql/sql_parse.cc:6235
 
#25 0x00000000007d8b3f in dispatch_command (command=COM_QUERY, thd=0x3972a90, packet=0x38fb8a1 "", packet_length=16) at mysql-5.6/sql/sql_parse.cc:1334
 
#26 0x00000000007d7c9d in do_command (thd=0x3972a90) at mysql-5.6/sql/sql_parse.cc:1036
 
#27 0x000000000079ec73 in do_handle_one_connection (thd_arg=0x346c3b0) at mysql-5.6/sql/sql_connect.cc:982
 
#28 0x000000000079e706 in handle_one_connection (arg=0x346c3b0) at mysql-5.6/sql/sql_connect.cc:898
 
#29 0x0000000000afec95 in pfs_spawn_thread (arg=0x390aec0) at mysql-5.6/storage/perfschema/pfs.cc:1858
 
#30 0x00007f1d81be7e9a in start_thread (arg=0x7f1d6a00b700) at pthread_create.c:308
 
#31 0x00007f1d81102cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112



 Comments   
Comment by Elena Stepanova [ 2013-11-13 ]

Same happens with TIME(N).
With DATETIME(N), there is no assertion failure, but data gets corrupted (even without ALTER from MDEV-5248, although ALTER breaks it further):

10.0:

MariaDB [test]> create table t1 (dt datetime(6)) engine=InnoDB;
Query OK, 0 rows affected (0.55 sec)

MariaDB [test]> insert into t1 values ('2012-12-21 12:12:12.121212');
Query OK, 1 row affected (0.22 sec)

5.6:

MySQL [test]> select * from t1;
---------------------

dt

---------------------

Q950-67-42 55:89:77

---------------------
1 row in set (0.01 sec)

MySQL [test]> alter table t1 add x int;
Query OK, 0 rows affected (1.25 sec)
Records: 0 Duplicates: 0 Warnings: 0

MySQL [test]> select * from t1;
---------------------------+

dt x

---------------------------+

’0('./.. :,:' NULL

---------------------------+
1 row in set (0.00 sec)

Comment by Sergei Golubchik [ 2013-11-13 ]

There's nothing we can do about it. MySQL doesn't know about MariaDB's temporal types with microsecond precision.

MariaDB knows about MySQL types, so MySQL→MariaDB migration works.

We're considering a feature that will allow MariaDB to create MySQL-compatible temporal types, though. While not a fix, it might be a workaround for this bug.

Generated at Thu Feb 08 07:03:06 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.