BUG#29152 - INSERT DELAYED does not use concurrent_insert on slave

INSERT DELAYED on a replication slave was converted to regular INSERT,
whereas it should try concurrent INSERT first.

With this patch we try to convert delayed insert to concurrent insert on
a replication slave. If it is impossible for some reason, we fall back to
regular insert.

No test case for this fix. I do not see anything indicating this is
regression - we behave this way since Nov 2000.


sql/sql_insert.cc:
  If we're executing INSERT DELAYED on a replication slave, we're upgrading
  lock type to TL_WRITE as we need to ensure serial execution of queries on
  the slave.
  
  OTOH if we're executing regular INSERT on a replication slave, we're
  trying TL_WRITE_CONCURRENT_INSERT first, and if we may not use it, we
  fall back to TL_WRITE.
  
  Fixed INSERT DELAYED on a replication slave to behave the same way as
  regular INSERT, that is to try TL_WRITE_CONCURRENT_INSERT first.

sql/sql_insert.cc

@@ -446,7 +446,6 @@ void upgrade_lock_type(THD *thd, thr_lock_type *lock_type,
         client connection and the delayed thread.
     */
     if (specialflag & (SPECIAL_NO_NEW_FUNC | SPECIAL_SAFE_MODE) ||
-        thd->slave_thread ||
         thd->variables.max_insert_delayed_threads == 0 ||
         thd->prelocked_mode ||
         thd->lex->uses_stored_routines())
@@ -454,6 +453,14 @@ void upgrade_lock_type(THD *thd, thr_lock_type *lock_type,
       *lock_type= TL_WRITE;
       return;
     }
+    if (thd->slave_thread)
+    {
+      /* Try concurrent insert */
+      *lock_type= (duplic == DUP_UPDATE || duplic == DUP_REPLACE) ?
+                  TL_WRITE : TL_WRITE_CONCURRENT_INSERT;
+      return;
+    }
+
     bool log_on= (thd->options & OPTION_BIN_LOG ||
                   ! (thd->security_ctx->master_access & SUPER_ACL));
     if (log_on && mysql_bin_log.is_open() && is_multi_insert)