Bug #14262: SP: DROP PROCEDURE|VIEW (maybe more) write to binlog too late \

	(race cond)

It was possible for one thread to interrupt a Data Definition Language 
statement and thereby get messages to the binlog out of order.  Consider:

Connection 1: Drop Foo x
Connection 2: Create or replace Foo x
Connection 2: Log "Create or replace Foo x"
Connection 1: Log "Drop Foo x"

Local end would have Foo x, but the replicated slaves would not.

The fix for this is to wrap all DDL and logging of a kind in the same mutex.  
Since we already use mutexes for the various parts of altering the server, 
this only entails moving the logging events down close to the action, inside 
the mutex protection.

1 files changed, 5 insertions, 3 deletions

diff --git a/sql/sql_trigger.cc b/sql/sql_trigger.cc
index 66a16f16d8c..6ff8a0620f4 100644
--- a/sql/sql_trigger.cc
+++ b/sql/sql_trigger.cc
@@ -268,8 +268,6 @@ bool mysql_create_or_drop_trigger(THD *thd, TABLE_LIST *tables, bool create)
            table->triggers->drop_trigger(thd, tables));
 
 end:
-  VOID(pthread_mutex_unlock(&LOCK_open));
-  start_waiting_global_read_lock(thd);
 
   if (!result)
   {
@@ -302,9 +300,13 @@ end:
       Query_log_event qinfo(thd, log_query.ptr(), log_query.length(), 0, FALSE);
       mysql_bin_log.write(&qinfo);
     }
+  }
+
+  VOID(pthread_mutex_unlock(&LOCK_open));
+  start_waiting_global_read_lock(thd);
 
+  if (!result)
     send_ok(thd);
-  }
 
   DBUG_RETURN(result);
 }