List:Commits« Previous MessageNext Message »
From:Mats Kindahl Date:June 15 2007 11:51am
Subject:bk commit into 5.1 tree (mats:1.2556) BUG#29130
View as plain text  
Below is the list of changes that have just been committed into a local
5.1 repository of mats. When mats does a push these changes will
be propagated to the main repository and, within 24 hours after the
push, to the public repository.
For information on how to access the public repository
see http://dev.mysql.com/doc/mysql/en/installing-source-tree.html

ChangeSet@stripped, 2007-06-15 13:50:56+02:00, mats@stripped +1 -0
  BUG#29130 (The logic for using delete_all_rows() is wrong):
  Correcting the logic for deciding when to use delete_all_rows() so that
  the behavior of TRUNCATE to not be dependent on binary logging
  format in effect.
  
  A TRUNCATE statement is always logged as a statement, so in this case,
  delete_all_rows() can always be used provided the other logic is correct.
  If a DELETE FROM without a WHERE clause is used, and row-based binlogging
  is used, the rows has to be deleted from the table on a per-row basis.

  sql/sql_delete.cc@stripped, 2007-06-15 13:50:51+02:00, mats@stripped +16 -4
    The logic for deciding when to use delete_all_rows() was altered so that
    the format used for binary logging does not affect how TRUNCATE is
    handled.

# This is a BitKeeper patch.  What follows are the unified diffs for the
# set of deltas contained in the patch.  The rest of the patch, the part
# that BitKeeper cares about, is below these diffs.
# User:	mats
# Host:	kindahl-laptop.dnsalias.net
# Root:	/home/bk/b24954-mysql-5.1-new-rpl

--- 1.221/sql/sql_delete.cc	2007-06-15 13:51:06 +02:00
+++ 1.222/sql/sql_delete.cc	2007-06-15 13:51:06 +02:00
@@ -90,14 +90,26 @@
     Test if the user wants to delete all rows and deletion doesn't have
     any side-effects (because of triggers), so we can use optimized
     handler::delete_all_rows() method.
-    We implement fast TRUNCATE for InnoDB even if triggers are present. 
-    TRUNCATE ignores triggers.
+
+    We implement fast TRUNCATE for InnoDB even if triggers are
+    present.  TRUNCATE ignores triggers.
+
+    We can use delete_all_rows() if and only if:
+    - We allow new functions (not using option --skip-new), and are
+      not in safe mode (not using option --safe-mode)
+    - There is no limit clause
+    - The condition is constant
+    - If there is a condition, then it it produces a non-zero value
+    - If the current command is DELETE FROM with no where clause
+      (i.e., not TRUNCATE) then:
+      - We should not be binlogging this statement row-based, and
+      - there should be no delete triggers associated with the table.
   */
   if (!using_limit && const_cond && (!conds || conds->val_int()) &&
       !(specialflag & (SPECIAL_NO_NEW_FUNC | SPECIAL_SAFE_MODE)) &&
       (thd->lex->sql_command == SQLCOM_TRUNCATE ||
-       !(table->triggers && table->triggers->has_delete_triggers())) &&
-      !thd->current_stmt_binlog_row_based)
+       (!thd->current_stmt_binlog_row_based &&
+        !(table->triggers && table->triggers->has_delete_triggers()))))
   {
     /* Update the table->file->stats.records number */
     table->file->info(HA_STATUS_VARIABLE | HA_STATUS_NO_LOCK);
Thread
bk commit into 5.1 tree (mats:1.2556) BUG#29130Mats Kindahl15 Jun