CREATE SELECT starts transaction with ::store_lock and at the wrong time

Bug #556978 reported by Stewart Smith on 2010-04-07
This bug affects 1 person
Affects Status Importance Assigned to Milestone
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=[a-zA-Z]+/ENGINE=DEFAULT/
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_history_cursor_first.c -linnodb -g
(ignore the compiler warnings)
and run.
(you will need to clean up the created files for each run)

also see,1177,1177#msg-1177

Stewart Smith (stewart) wrote :
Lee Bieber (kalebral) on 2010-04-11
Changed in drizzle:
assignee: nobody → Stewart Smith (stewart-flamingspork)
Stewart Smith (stewart) on 2010-05-25
tags: added: storage-engine-api
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers