bzr commit into mysql-5.5.0-next-mr-runtime branch (magne.mahre:2925) Bug#37433

[Magne Mahre]

#At file:///data/z/mysql-next-mr-runtime/ based on revid:magne.mahre@stripped

 2925 Magne Mahre	2009-10-15
      Bug #37433  	Deadlock between open_table, close_open_tables, 
                      get_table_share, drop_open_table
                  
      In the partition handler code, LOCK_open and share->LOCK_ha_data
      are acquired in the wrong order in certain cases.  When doing a
      multi-row INSERT (i.e a INSERT..SELECT) in a table with auto-
      increment column(s). the increments must be in a monotonically
      continuous increasing sequence (i.e it can't have "holes"). To
      achieve this, a lock is held for the duration of the operation.
      share->LOCK_ha_data was used for this purpose.
                  
      Whenever there was a need to open a view _during_ the operation
      (views are not currently pre-opened the way tables are), and
      LOCK_open was grabbed, a deadlock could occur.  share->LOCK_ha_data
      is other places used _while_ holding LOCK_open.
                  
      A new mutex was introduced in the HA_DATA_PARTITION structure,
      for exclusive use of the autoincrement data fields, so we don't
      need to overload the use of LOCK_ha_data here.
                  
      A module test case has not been supplied, since the problem occurs
      as a result of a race condition, and testing for this condition 
      is thus not deterministic.   Testing for it could be done by
      setting up a test case as described in the bug report.

    modified:
      sql/ha_partition.cc
      sql/ha_partition.h
      sql/table.cc
      sql/table.h
=== modified file 'sql/ha_partition.cc'
--- a/sql/ha_partition.cc	2009-09-28 07:39:50 +0000
+++ b/sql/ha_partition.cc	2009-10-15 11:07:04 +0000
@@ -2452,6 +2452,21 @@ err1:
 /****************************************************************************
                 MODULE open/close object
 ****************************************************************************/
+
+
+/**
+  A destructor for partition-specific TABLE_SHARE data.
+*/
+
+void ha_data_partition_destroy(void *ha_data)
+{
+  if (ha_data)
+  {
+    HA_DATA_PARTITION *ha_data_partition= (HA_DATA_PARTITION*) ha_data;
+    pthread_mutex_destroy(&ha_data_partition->mutex);
+  }
+}
+
 /*
   Open handler object
 
@@ -2608,6 +2623,8 @@ int ha_partition::open(const char *name,
     }
     DBUG_PRINT("info", ("table_share->ha_data 0x%p", ha_data));
     bzero(ha_data, sizeof(HA_DATA_PARTITION));
+    table_share->ha_data_destroy= ha_data_partition_destroy;
+    pthread_mutex_init(&ha_data->mutex, MY_MUTEX_INIT_FAST);
   }
   if (is_not_tmp_table)
     pthread_mutex_unlock(&table_share->mutex);

=== modified file 'sql/ha_partition.h'
--- a/sql/ha_partition.h	2009-09-28 07:39:50 +0000
+++ b/sql/ha_partition.h	2009-10-15 11:07:04 +0000
@@ -45,6 +45,7 @@ typedef struct st_ha_data_partition
 {
   ulonglong next_auto_inc_val;                 /**< first non reserved value */
   bool auto_inc_initialized;
+  pthread_mutex_t mutex;
 } HA_DATA_PARTITION;
 
 #define PARTITION_BYTES_IN_POS 2

=== modified file 'sql/table.cc'
--- a/sql/table.cc	2009-10-14 16:37:38 +0000
+++ b/sql/table.cc	2009-10-15 11:07:04 +0000
@@ -1601,6 +1601,8 @@ static int open_binary_frm(THD *thd, TAB
   delete crypted;
   delete handler_file;
   my_hash_free(&share->name_hash);
+  if (share->ha_data_destroy)
+    share->ha_data_destroy(share->ha_data);
 
   open_table_error(share, error, share->open_errno, errarg);
   DBUG_RETURN(error);

=== modified file 'sql/table.h'
--- a/sql/table.h	2009-10-14 11:14:58 +0000
+++ b/sql/table.h	2009-10-15 11:07:04 +0000
@@ -419,6 +419,7 @@ struct TABLE_SHARE
 
   /** place to store storage engine specific data */
   void *ha_data;
+  void (*ha_data_destroy)(void *); /* An optional destructor for ha_data */
 
 
   /*


Attachment: [text/bzr-bundle] bzr/[e-mail]