List:Commits« Previous MessageNext Message »
From:Luis Soares Date:October 13 2010 2:17pm
Subject:bzr commit into mysql-5.5-bugteam branch (luis.soares:3241) Bug#57288
View as plain text  
#At file:///home/lsoares/Workspace/bzr/work/bugfixing/57288/mysql-5.5-bugteam/ based on revid:alexander.nozdrin@stripped

 3241 Luis Soares	2010-10-13 [merge]
      BUG#57288: binlog_tmp_table fails sporadically: "Failed to write
      the DROP statement ..."
      Problem: When using temporary tables and closing a session, an
      implicit DROP TEMPORARY TABLE IF EXISTS is written to the binary
      log (while cleaning up the context of the session THD - see: which calls close_temporary_tables).
      close_temporary_tables, first checks if the binary log is opened
      and then proceeds to creating the DROP statements. Then, such
      statements, are written to the binary log through
      MYSQL_BIN_LOG::write(Log_event *). Inside, there is another check
      if the binary log is opened and if not an error is returned. This
      is where the faulty behavior is triggered. Given that the test
      case replays a binary log, with temp tables statements, and right
      after it issues RESET MASTER, there is a chance that is_open will
      report false (when the mysql session is closed and the temporary
      tables are written). 
      is_open may return false, because MYSQL_BIN_LOG::reset_logs is
      not setting the correct flag (LOG_CLOSE_TO_BE_OPENED), on the
      MYSQL_LOG_BIN::log_state (instead it sets just the
      LOG_CLOSE_INDEX flag, leaving the log_state to
      LOG_CLOSED). Thence, when writing the DROP statement as part of
      the THD::cleanup, the thread could get a return value of false
      for is_open - inside MYSQL_BIN_LOG::write, ultimately reporting
      that it can't write the event to the binary log.
      Fix: We fix this by adding the correct flag, missing in the
      second close. Additionally, we also make the assignment of
      log_file to be protected inside MYSQL_BIN_LOG::write, which could
      also lead to potential races.

=== modified file 'sql/'
--- a/sql/	2010-09-29 14:26:32 +0000
+++ b/sql/	2010-10-13 14:15:36 +0000
@@ -3295,7 +3295,7 @@ bool MYSQL_BIN_LOG::reset_logs(THD* thd)
   /* Start logging with a new file */
-  close(LOG_CLOSE_INDEX);
   if ((error= my_delete_allow_opened(index_file_name, MYF(0))))	// Reset (open will update)
     if (my_errno == ENOENT) 
@@ -4693,8 +4693,8 @@ bool MYSQL_BIN_LOG::write(Log_event *eve
     if (event_info->use_direct_logging())
-      file= &log_file;
+      file= &log_file;

Attachment: [text/bzr-bundle] bzr/
bzr commit into mysql-5.5-bugteam branch (luis.soares:3241) Bug#57288Luis Soares13 Oct
  • Re: bzr commit into mysql-5.5-bugteam branch (luis.soares:3241) Bug#57288Alfranio Correia14 Oct
    • Re: bzr commit into mysql-5.5-bugteam branch (luis.soares:3241) Bug#57288Luís Soares15 Oct
      • Re: bzr commit into mysql-5.5-bugteam branch (luis.soares:3241) Bug#57288Alfranio Correia15 Oct
  • Re: bzr commit into mysql-5.5-bugteam branch (luis.soares:3241) Bug#57288Sven Sandberg20 Oct