Bug #34006 binlog race for temporary ndb table
Submitted: 23 Jan 2008 14:01 Modified: 23 Jan 2008 14:13
Reporter: Tomas Ulin
Status: Verified
Category:Server: ClusterRep Severity:S3 (Non-critical)
Version:mysql-5.1-telco-6.3 OS:Any
Assigned to: Martin Skold Target Version:CGE
Triage: Triaged: D1 (Critical)

[23 Jan 2008 14:01] Tomas Ulin 
Description:
when implementing wl#4225 create/alter/drop tables are so fast that they happen before
data reaches the binlog

How to repeat:
run rpl_ndb_2myisam and uncomment workaround
[23 Jan 2008 14:03] Bugs System 
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/41151

ChangeSet@1.2841, 2008-01-23 14:03:37+01:00, tomas@poseidon.ndb.mysql.com +3 -0
  disable temp table usage as tes need disk persistant tables
  workaround for bug#34006
[23 Jan 2008 14:13] Tomas Ulin 
../client/mysqlbinlog var/log/master-bin.000001

... error in binlog (wrong name in table map):

#080123 14:12:47 server id 1  end_log_pos 7076  Table_map: `test`.`#sql2-5272-3` mapped to
number 28
#080123 14:12:47 server id 1  end_log_pos 7138  Table_map: `mysql`.`ndb_apply_status`
mapped to number 16
#080123 14:12:47 server id 1  end_log_pos 7197  Write_rows: table id 16
#080123 14:12:47 server id 1  end_log_pos 7631  Delete_rows: table id 28 flags:
STMT_END_F
[1 Feb 2008 14:07] Jon Stephens 
Documented bug fix for 5.1.23-ndb-6.3.8 as follows:

        Consecutive DDL statements involving tables (CREATE
        TABLE, ALTER TABLE, and
        DROP TABLE) could be executed so quickly that
        previous DDL statements upon which they depended were not yet
        written in the binary log.  
      
      
      
        For example, if DROP TABLE foo was issued
        immediately following CREATE TABLE foo, the
        DROP statement could fail because the
        CREATE had not yet been recorded.

Left bug status as Verified pending further commits/merges.