You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

188 lines
5.7 KiB

Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock - Incompatible change: truncate no longer resorts to a row by row delete if the storage engine does not support the truncate method. Consequently, the count of affected rows does not, in any case, reflect the actual number of rows. - Incompatible change: it is no longer possible to truncate a table that participates as a parent in a foreign key constraint, unless it is a self-referencing constraint (both parent and child are in the same table). To work around this incompatible change and still be able to truncate such tables, disable foreign checks with SET foreign_key_checks=0 before truncate. Alternatively, if foreign key checks are necessary, please use a DELETE statement without a WHERE condition. Problem description: The problem was that for storage engines that do not support truncate table via a external drop and recreate, such as InnoDB which implements truncate via a internal drop and recreate, the delete_all_rows method could be invoked with a shared metadata lock, causing problems if the engine needed exclusive access to some internal metadata. This problem originated with the fact that there is no truncate specific handler method, which ended up leading to a abuse of the delete_all_rows method that is primarily used for delete operations without a condition. Solution: The solution is to introduce a truncate handler method that is invoked when the engine does not support truncation via a table drop and recreate. This method is invoked under a exclusive metadata lock, so that there is only a single instance of the table when the method is invoked. Also, the method is not invoked and a error is thrown if the table is a parent in a non-self-referencing foreign key relationship. This was necessary to avoid inconsistency as some integrity checks are bypassed. This is inline with the fact that truncate is primarily a DDL operation that was designed to quickly remove all data from a table.
15 years ago
Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock - Incompatible change: truncate no longer resorts to a row by row delete if the storage engine does not support the truncate method. Consequently, the count of affected rows does not, in any case, reflect the actual number of rows. - Incompatible change: it is no longer possible to truncate a table that participates as a parent in a foreign key constraint, unless it is a self-referencing constraint (both parent and child are in the same table). To work around this incompatible change and still be able to truncate such tables, disable foreign checks with SET foreign_key_checks=0 before truncate. Alternatively, if foreign key checks are necessary, please use a DELETE statement without a WHERE condition. Problem description: The problem was that for storage engines that do not support truncate table via a external drop and recreate, such as InnoDB which implements truncate via a internal drop and recreate, the delete_all_rows method could be invoked with a shared metadata lock, causing problems if the engine needed exclusive access to some internal metadata. This problem originated with the fact that there is no truncate specific handler method, which ended up leading to a abuse of the delete_all_rows method that is primarily used for delete operations without a condition. Solution: The solution is to introduce a truncate handler method that is invoked when the engine does not support truncation via a table drop and recreate. This method is invoked under a exclusive metadata lock, so that there is only a single instance of the table when the method is invoked. Also, the method is not invoked and a error is thrown if the table is a parent in a non-self-referencing foreign key relationship. This was necessary to avoid inconsistency as some integrity checks are bypassed. This is inline with the fact that truncate is primarily a DDL operation that was designed to quickly remove all data from a table.
15 years ago
Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock - Incompatible change: truncate no longer resorts to a row by row delete if the storage engine does not support the truncate method. Consequently, the count of affected rows does not, in any case, reflect the actual number of rows. - Incompatible change: it is no longer possible to truncate a table that participates as a parent in a foreign key constraint, unless it is a self-referencing constraint (both parent and child are in the same table). To work around this incompatible change and still be able to truncate such tables, disable foreign checks with SET foreign_key_checks=0 before truncate. Alternatively, if foreign key checks are necessary, please use a DELETE statement without a WHERE condition. Problem description: The problem was that for storage engines that do not support truncate table via a external drop and recreate, such as InnoDB which implements truncate via a internal drop and recreate, the delete_all_rows method could be invoked with a shared metadata lock, causing problems if the engine needed exclusive access to some internal metadata. This problem originated with the fact that there is no truncate specific handler method, which ended up leading to a abuse of the delete_all_rows method that is primarily used for delete operations without a condition. Solution: The solution is to introduce a truncate handler method that is invoked when the engine does not support truncation via a table drop and recreate. This method is invoked under a exclusive metadata lock, so that there is only a single instance of the table when the method is invoked. Also, the method is not invoked and a error is thrown if the table is a parent in a non-self-referencing foreign key relationship. This was necessary to avoid inconsistency as some integrity checks are bypassed. This is inline with the fact that truncate is primarily a DDL operation that was designed to quickly remove all data from a table.
15 years ago
Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock - Incompatible change: truncate no longer resorts to a row by row delete if the storage engine does not support the truncate method. Consequently, the count of affected rows does not, in any case, reflect the actual number of rows. - Incompatible change: it is no longer possible to truncate a table that participates as a parent in a foreign key constraint, unless it is a self-referencing constraint (both parent and child are in the same table). To work around this incompatible change and still be able to truncate such tables, disable foreign checks with SET foreign_key_checks=0 before truncate. Alternatively, if foreign key checks are necessary, please use a DELETE statement without a WHERE condition. Problem description: The problem was that for storage engines that do not support truncate table via a external drop and recreate, such as InnoDB which implements truncate via a internal drop and recreate, the delete_all_rows method could be invoked with a shared metadata lock, causing problems if the engine needed exclusive access to some internal metadata. This problem originated with the fact that there is no truncate specific handler method, which ended up leading to a abuse of the delete_all_rows method that is primarily used for delete operations without a condition. Solution: The solution is to introduce a truncate handler method that is invoked when the engine does not support truncation via a table drop and recreate. This method is invoked under a exclusive metadata lock, so that there is only a single instance of the table when the method is invoked. Also, the method is not invoked and a error is thrown if the table is a parent in a non-self-referencing foreign key relationship. This was necessary to avoid inconsistency as some integrity checks are bypassed. This is inline with the fact that truncate is primarily a DDL operation that was designed to quickly remove all data from a table.
15 years ago
Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock - Incompatible change: truncate no longer resorts to a row by row delete if the storage engine does not support the truncate method. Consequently, the count of affected rows does not, in any case, reflect the actual number of rows. - Incompatible change: it is no longer possible to truncate a table that participates as a parent in a foreign key constraint, unless it is a self-referencing constraint (both parent and child are in the same table). To work around this incompatible change and still be able to truncate such tables, disable foreign checks with SET foreign_key_checks=0 before truncate. Alternatively, if foreign key checks are necessary, please use a DELETE statement without a WHERE condition. Problem description: The problem was that for storage engines that do not support truncate table via a external drop and recreate, such as InnoDB which implements truncate via a internal drop and recreate, the delete_all_rows method could be invoked with a shared metadata lock, causing problems if the engine needed exclusive access to some internal metadata. This problem originated with the fact that there is no truncate specific handler method, which ended up leading to a abuse of the delete_all_rows method that is primarily used for delete operations without a condition. Solution: The solution is to introduce a truncate handler method that is invoked when the engine does not support truncation via a table drop and recreate. This method is invoked under a exclusive metadata lock, so that there is only a single instance of the table when the method is invoked. Also, the method is not invoked and a error is thrown if the table is a parent in a non-self-referencing foreign key relationship. This was necessary to avoid inconsistency as some integrity checks are bypassed. This is inline with the fact that truncate is primarily a DDL operation that was designed to quickly remove all data from a table.
15 years ago
Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock - Incompatible change: truncate no longer resorts to a row by row delete if the storage engine does not support the truncate method. Consequently, the count of affected rows does not, in any case, reflect the actual number of rows. - Incompatible change: it is no longer possible to truncate a table that participates as a parent in a foreign key constraint, unless it is a self-referencing constraint (both parent and child are in the same table). To work around this incompatible change and still be able to truncate such tables, disable foreign checks with SET foreign_key_checks=0 before truncate. Alternatively, if foreign key checks are necessary, please use a DELETE statement without a WHERE condition. Problem description: The problem was that for storage engines that do not support truncate table via a external drop and recreate, such as InnoDB which implements truncate via a internal drop and recreate, the delete_all_rows method could be invoked with a shared metadata lock, causing problems if the engine needed exclusive access to some internal metadata. This problem originated with the fact that there is no truncate specific handler method, which ended up leading to a abuse of the delete_all_rows method that is primarily used for delete operations without a condition. Solution: The solution is to introduce a truncate handler method that is invoked when the engine does not support truncation via a table drop and recreate. This method is invoked under a exclusive metadata lock, so that there is only a single instance of the table when the method is invoked. Also, the method is not invoked and a error is thrown if the table is a parent in a non-self-referencing foreign key relationship. This was necessary to avoid inconsistency as some integrity checks are bypassed. This is inline with the fact that truncate is primarily a DDL operation that was designed to quickly remove all data from a table.
15 years ago
Bug#49938: Failing assertion: inode or deadlock in fsp/fsp0fsp.c Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock - Incompatible change: truncate no longer resorts to a row by row delete if the storage engine does not support the truncate method. Consequently, the count of affected rows does not, in any case, reflect the actual number of rows. - Incompatible change: it is no longer possible to truncate a table that participates as a parent in a foreign key constraint, unless it is a self-referencing constraint (both parent and child are in the same table). To work around this incompatible change and still be able to truncate such tables, disable foreign checks with SET foreign_key_checks=0 before truncate. Alternatively, if foreign key checks are necessary, please use a DELETE statement without a WHERE condition. Problem description: The problem was that for storage engines that do not support truncate table via a external drop and recreate, such as InnoDB which implements truncate via a internal drop and recreate, the delete_all_rows method could be invoked with a shared metadata lock, causing problems if the engine needed exclusive access to some internal metadata. This problem originated with the fact that there is no truncate specific handler method, which ended up leading to a abuse of the delete_all_rows method that is primarily used for delete operations without a condition. Solution: The solution is to introduce a truncate handler method that is invoked when the engine does not support truncation via a table drop and recreate. This method is invoked under a exclusive metadata lock, so that there is only a single instance of the table when the method is invoked. Also, the method is not invoked and a error is thrown if the table is a parent in a non-self-referencing foreign key relationship. This was necessary to avoid inconsistency as some integrity checks are bypassed. This is inline with the fact that truncate is primarily a DDL operation that was designed to quickly remove all data from a table.
15 years ago
  1. /* Copyright (c) 2010 Oracle and/or its affiliates. All rights reserved.
  2. This program is free software; you can redistribute it and/or modify
  3. it under the terms of the GNU General Public License as published by
  4. the Free Software Foundation; version 2 of the License.
  5. This program is distributed in the hope that it will be useful,
  6. but WITHOUT ANY WARRANTY; without even the implied warranty of
  7. MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
  8. GNU General Public License for more details.
  9. You should have received a copy of the GNU General Public License
  10. along with this program; if not, write to the Free Software
  11. Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */
  12. #include "sql_parse.h" // check_one_table_access
  13. #include "sql_table.h" // mysql_alter_table, etc.
  14. #include "sql_lex.h" // Sql_statement
  15. #include "sql_admin.h" // Analyze/Check/.._table_statement
  16. #include "sql_partition_admin.h" // Alter_table_*_partition
  17. #include "ha_partition.h" // ha_partition
  18. #include "sql_base.h" // open_and_lock_tables
  19. #ifndef WITH_PARTITION_STORAGE_ENGINE
  20. bool Partition_statement_unsupported::execute(THD *)
  21. {
  22. DBUG_ENTER("Partition_statement_unsupported::execute");
  23. /* error, partitioning support not compiled in... */
  24. my_error(ER_FEATURE_DISABLED, MYF(0), "partitioning",
  25. "--with-plugin-partition");
  26. DBUG_RETURN(TRUE);
  27. }
  28. #else
  29. bool Alter_table_analyze_partition_statement::execute(THD *thd)
  30. {
  31. bool res;
  32. DBUG_ENTER("Alter_table_analyze_partition_statement::execute");
  33. /*
  34. Flag that it is an ALTER command which administrates partitions, used
  35. by ha_partition
  36. */
  37. m_lex->alter_info.flags|= ALTER_ADMIN_PARTITION;
  38. res= Analyze_table_statement::execute(thd);
  39. DBUG_RETURN(res);
  40. }
  41. bool Alter_table_check_partition_statement::execute(THD *thd)
  42. {
  43. bool res;
  44. DBUG_ENTER("Alter_table_check_partition_statement::execute");
  45. /*
  46. Flag that it is an ALTER command which administrates partitions, used
  47. by ha_partition
  48. */
  49. m_lex->alter_info.flags|= ALTER_ADMIN_PARTITION;
  50. res= Check_table_statement::execute(thd);
  51. DBUG_RETURN(res);
  52. }
  53. bool Alter_table_optimize_partition_statement::execute(THD *thd)
  54. {
  55. bool res;
  56. DBUG_ENTER("Alter_table_optimize_partition_statement::execute");
  57. /*
  58. Flag that it is an ALTER command which administrates partitions, used
  59. by ha_partition
  60. */
  61. m_lex->alter_info.flags|= ALTER_ADMIN_PARTITION;
  62. res= Optimize_table_statement::execute(thd);
  63. DBUG_RETURN(res);
  64. }
  65. bool Alter_table_repair_partition_statement::execute(THD *thd)
  66. {
  67. bool res;
  68. DBUG_ENTER("Alter_table_repair_partition_statement::execute");
  69. /*
  70. Flag that it is an ALTER command which administrates partitions, used
  71. by ha_partition
  72. */
  73. m_lex->alter_info.flags|= ALTER_ADMIN_PARTITION;
  74. res= Repair_table_statement::execute(thd);
  75. DBUG_RETURN(res);
  76. }
  77. bool Alter_table_truncate_partition_statement::execute(THD *thd)
  78. {
  79. int error;
  80. ha_partition *partition;
  81. ulong timeout= thd->variables.lock_wait_timeout;
  82. TABLE_LIST *first_table= thd->lex->select_lex.table_list.first;
  83. DBUG_ENTER("Alter_table_truncate_partition_statement::execute");
  84. /*
  85. Flag that it is an ALTER command which administrates partitions, used
  86. by ha_partition.
  87. */
  88. m_lex->alter_info.flags|= ALTER_ADMIN_PARTITION |
  89. ALTER_TRUNCATE_PARTITION;
  90. /* Fix the lock types (not the same as ordinary ALTER TABLE). */
  91. first_table->lock_type= TL_WRITE;
  92. first_table->mdl_request.set_type(MDL_EXCLUSIVE);
  93. /*
  94. Check table permissions and open it with a exclusive lock.
  95. Ensure it is a partitioned table and finally, upcast the
  96. handler and invoke the partition truncate method. Lastly,
  97. write the statement to the binary log if necessary.
  98. */
  99. if (check_one_table_access(thd, DROP_ACL, first_table))
  100. DBUG_RETURN(TRUE);
  101. if (open_and_lock_tables(thd, first_table, FALSE, 0))
  102. DBUG_RETURN(TRUE);
  103. /*
  104. TODO: Add support for TRUNCATE PARTITION for NDB and other
  105. engines supporting native partitioning.
  106. */
  107. if (first_table->table->s->db_type() != partition_hton)
  108. {
  109. my_error(ER_PARTITION_MGMT_ON_NONPARTITIONED, MYF(0));
  110. DBUG_RETURN(TRUE);
  111. }
  112. /*
  113. Under locked table modes this might still not be an exclusive
  114. lock. Hence, upgrade the lock since the handler truncate method
  115. mandates an exclusive metadata lock.
  116. */
  117. MDL_ticket *ticket= first_table->table->mdl_ticket;
  118. if (thd->mdl_context.upgrade_shared_lock_to_exclusive(ticket, timeout))
  119. DBUG_RETURN(TRUE);
  120. tdc_remove_table(thd, TDC_RT_REMOVE_NOT_OWN, first_table->db,
  121. first_table->table_name, FALSE);
  122. partition= (ha_partition *) first_table->table->file;
  123. /* Invoke the handler method responsible for truncating the partition. */
  124. if ((error= partition->truncate_partition(&thd->lex->alter_info)))
  125. first_table->table->file->print_error(error, MYF(0));
  126. /*
  127. All effects of a truncate operation are committed even if the
  128. operation fails. Thus, the query must be written to the binary
  129. log. The only exception is a unimplemented truncate method. Also,
  130. it is logged in statement format, regardless of the binlog format.
  131. */
  132. if (error != HA_ERR_WRONG_COMMAND)
  133. error|= write_bin_log(thd, !error, thd->query(), thd->query_length());
  134. /*
  135. A locked table ticket was upgraded to a exclusive lock. After the
  136. the query has been written to the binary log, downgrade the lock
  137. to a shared one.
  138. */
  139. if (thd->locked_tables_mode)
  140. ticket->downgrade_exclusive_lock(MDL_SHARED_NO_READ_WRITE);
  141. if (! error)
  142. my_ok(thd);
  143. DBUG_RETURN(error);
  144. }
  145. #endif /* WITH_PARTITION_STORAGE_ENGINE */