Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 10.0.0, 5.5.28a, 10.0, 5.5
-
Component/s: Views
-
Labels:
Description
The following test case
--source include/have_binlog_format_statement.inc --write_file $MYSQLTEST_VARDIR/l.data 1 EOF CREATE TABLE t1 (i INT); CREATE VIEW v1 AS SELECT i FROM t1; --eval LOAD DATA LOCAL INFILE '$MYSQLTEST_VARDIR/l.data' INTO TABLE v1 (i)
causes an assertion failure with debug build or a crash with release build.
sql/sql_load.cc:745: bool write_execute_load_query_log_event(THD*, sql_exchange*, const char*, const char*, bool, enum_duplicates, bool, bool, int): Assertion `item->type() == Item::STRING_ITEM' failed. 141110 0:41:00 [ERROR] mysqld got signal 6 ;
#6 0x00007f47301e36f1 in *__GI___assert_fail (assertion=0xe37cf0 "item->type() == Item::STRING_ITEM", file=<optimized out>, line=745, function=0xe38720 "bool write_execute_load_query_log_event(THD*, sql_exchange*, const char*, const char*, bool, enum_duplicates, bool, bool, int)") at assert.c:81 #7 0x000000000093253a in write_execute_load_query_log_event (thd=0x7f472fb4b060, ex=0x7f472ae871c8, db_arg=0x7f472ae87818 "test", table_name_arg=0x7f472ae87218 "v1", is_concurrent=false, duplicates=DUP_ERROR, ignore=true, transactional_table=false, errcode=0) at 5.5/sql/sql_load.cc:745 #8 0x00000000009320cb in mysql_load (thd=0x7f472fb4b060, ex=0x7f472ae871c8, table_list=0x7f472ae87250, fields_vars=..., set_fields=..., set_values=..., handle_duplicates=DUP_ERROR, ignore=true, read_file_from_client=true) at 5.5/sql/sql_load.cc:653 #9 0x0000000000633ef1 in mysql_execute_command (thd=0x7f472fb4b060) at 5.5/sql/sql_parse.cc:3244 #10 0x000000000063ab1e in mysql_parse (thd=0x7f472fb4b060, rawbuf=0x7f472ae87078 "LOAD DATA LOCAL INFILE '/data/repo/bzr/5.5/mysql-test/var/l.data' INTO TABLE v1 (i)", length=83, parser_state=0x7f472b7b5630) at 5.5/sql/sql_parse.cc:5800 #11 0x000000000062eb39 in dispatch_command (command=COM_QUERY, thd=0x7f472fb4b060, packet=0x7f472bdee061 "", packet_length=83) at 5.5/sql/sql_parse.cc:1079 #12 0x000000000062dcc5 in do_command (thd=0x7f472fb4b060) at 5.5/sql/sql_parse.cc:793 #13 0x000000000072fed6 in do_handle_one_connection (thd_arg=0x7f472fb4b060) at 5.5/sql/sql_connect.cc:1266 #14 0x000000000072f995 in handle_one_connection (arg=0x7f472fb4b060) at 5.5/sql/sql_connect.cc:1181 #15 0x0000000000b65695 in pfs_spawn_thread (arg=0x7f472bd57ac0) at 5.5/storage/perfschema/pfs.cc:1015 #16 0x00007f4731985b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #17 0x00007f473029420d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
Stack trace from
revision-id: jplindst@mariadb.org-20141103134344-fn99l1w53xyhc43e date: 2014-11-03 15:43:44 +0200 build-date: 2014-11-10 00:42:08 +0400 revno: 4343 branch-nick: 5.5
Also reproducible on maria/10.0.
MySQL also has problems with this kind of statements, see bug http://bugs.mysql.com/bug.php?id=67878, but it doesn't crash on the scenario above.
Gliffy Diagrams
Attachments
Issue Links
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
The bug had a wrong description (fixed now), it said that the slave was crashing while in fact it was the master; it shouldn't have been marked as upstream at the first place. But anyway, the upstream replication problem has been fixed now in 5.7.1. Possibly when we fix the crash we'll get the same replication failure and then can consider merging the upstream bugfix.
revno: 5107.18.1
revision-id: venkatesh.duggirala@oracle.com-20130205051534-wydjb02g7tkuvc31
parent: sayantan.dutta@oracle.com-20130204152554-385j9txfp3eh810g
committer: Venkatesh Duggirala<venkatesh.duggirala@oracle.com>
branch nick: mysql-trunk
timestamp: Tue 2013-02-05 10:45:34 +0530
message:
Bug#15993712-REPLICATION FAILURE ON LOADING DATA INTO
A VIEW WITH BINLOG_FORMAT=STATEMENT
Replication breaks when a 'LOAD DATA' statement is
used against a view object. There are two problems
Problem 1): if field list is not explicitly
mentioned, then server expands all fields of the
base table, even those that aren't used in the view.
Fix: 'All fields' logic should look into view fields
only and should not be from the base table.
Problem 2): if field list is mentioned, then those
fields are expanded as qualified identifiers with base
table's name.
Eg: column 'i' in 'v1' expanded as `test.t1.i`
Fix: Do not expand the columns as qualified identifiers
Fixed in 5.7.1 (at least the comment at bugs.mysql.com says so)