parallel replication can't find the db just created.

[GoogleCodeExporter]

What steps will reproduce the problem?

1.  channels = 4
2. svc-parallelization-type=disk
3. Then run these commands:
DROP  DATABASE IF EXISTS test /*!*/;
CREATE DATABASE IF NOT EXISTS test /*!*/;
CREATE DATABASE IF NOT EXISTS rqg_admin /*!*/;
CREATE TABLE IF NOT EXISTS admin.test_suite (admin_id int unsigned 
auto_increment PRIMARY KEY, test_date datetime NOT NULL, test_name 
varchar(30),gendata varchar(64), grammar varchar(64),binlog_format varchar(10), 
exit_status varchar(10) ) /*!*/;
DROP DATABASE test /*!*/;
CREATE DATABASE test /*!*/;
CREATE SCHEMA /*!IF NOT EXISTS*/ test /*!*/;

What is the expected output?
Database "test" is dropped and created.
Database admin is created.
Table test_suite is created in the admin database.

What do you see instead?
Most, but not ALL of the time the create table fails as the admin database 
hasn't been created yet.

What is the possible cause?
Order of commands is incorrect.

...

What is the proposed solution?

...

Additional information

...

Use labels and text to provide additional information.

Original issue reported on code.google.com by eona...@gmail.com on 17 Aug 2011 at 1:38

• Blocked on: #8

[GoogleCodeExporter]

Please clarify:
 "admin" database != "rgq_admin"

This set of commands fails on the master as well.

Original comment by g.maxia on 17 Aug 2011 at 5:06

• Changed state: NonRepeatable

[GoogleCodeExporter]

This set reproduces the bug.

  create schema /*!IF NOT EXISTS*/ xyz;
  use xyz;
  create table /*!IF NOT EXISTS*/ t1(i int);

There are two consequences:
1) the commands using /*!IF NOT EXISTS*/ are assigned to the #UNKNOWN shard
2) The schema is not created.

Original comment by g.maxia on 17 Aug 2011 at 6:06

• Changed state: Accepted
• Added labels: FoundIn-2.0.4, Priority-Critical
• Removed labels: FoundIn, Priority-Medium

[GoogleCodeExporter]

Original comment by berkeley...@gmail.com on 26 Aug 2011 at 12:10

• Added labels: Durability

[GoogleCodeExporter]

I am pretty sure this is happening because of Issue 8.  We block in parallel 
replication until the event has been processed but not committed.  The 
replicator is pretty fast and can hit race conditions if you don't correct 
serialize before letting another thread go ahead. 

Original comment by berkeley...@gmail.com on 13 Oct 2011 at 10:37

[GoogleCodeExporter]

Original comment by robert.h...@continuent.com on 23 Jan 2012 at 6:50

[GoogleCodeExporter]

This should be corrected by the Issue 8 fix. 

Original comment by robert.h...@continuent.com on 8 Sep 2012 at 8:21

• Now blocked on: #8