CREATE SELECT starts transaction with ::store_lock and at the wrong time
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Drizzle |
Confirmed
|
Medium
|
Stewart Smith |
Bug Description
create table t1 (d double primary key);
create table t2 (d double primary key);
insert into t1 values ("100000000.0");
insert into t2 values ("1.23456780");
create table t3 (d double primary key) as select t2.d from t2 union select t1.d from t1;
select * from t3;
--replace_regex /ENGINE=
show create table t3;
drop table t1, t2, t3;
The create table t3 statement will get ::store_lock to start transaction. transaction is started for t1 and t2, then the table is created, then ::write_row is attempted on t3.
transaction will not have t3 in its snapshot, and then ::write_row can fail.
You can see the direct innodb calls that are made to get to this situation in the attached source file. build with:
gcc missing_
(ignore the compiler warnings)
and run.
(you will need to clean up the created files for each run)
also see http://
Changed in drizzle: | |
assignee: | nobody → Stewart Smith (stewart-flamingspork) |
tags: | added: storage-engine-api |