2014-01-06 10:52:35 +05:30
|
|
|
/* Copyright (c) 2010, 2013, Oracle and/or its affiliates. All rights reserved.
|
2010-08-16 14:53:30 +02:00
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation; version 2 of the License.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with this program; if not, write to the Free Software
|
|
|
|
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */
|
|
|
|
|
|
|
|
#include "sql_parse.h" // check_one_table_access
|
|
|
|
#include "sql_table.h" // mysql_alter_table, etc.
|
|
|
|
#include "sql_lex.h" // Sql_statement
|
2010-08-16 16:25:23 +02:00
|
|
|
#include "sql_admin.h" // Analyze/Check/.._table_statement
|
2010-08-16 14:53:30 +02:00
|
|
|
#include "sql_partition_admin.h" // Alter_table_*_partition
|
2010-10-28 12:08:09 +02:00
|
|
|
#ifdef WITH_PARTITION_STORAGE_ENGINE
|
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.
2010-10-06 11:34:28 -03:00
|
|
|
#include "ha_partition.h" // ha_partition
|
2010-10-28 12:08:09 +02:00
|
|
|
#endif
|
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.
2010-10-06 11:34:28 -03:00
|
|
|
#include "sql_base.h" // open_and_lock_tables
|
2010-08-16 14:53:30 +02:00
|
|
|
|
|
|
|
#ifndef WITH_PARTITION_STORAGE_ENGINE
|
|
|
|
|
|
|
|
bool Partition_statement_unsupported::execute(THD *)
|
|
|
|
{
|
|
|
|
DBUG_ENTER("Partition_statement_unsupported::execute");
|
|
|
|
/* error, partitioning support not compiled in... */
|
|
|
|
my_error(ER_FEATURE_DISABLED, MYF(0), "partitioning",
|
|
|
|
"--with-plugin-partition");
|
|
|
|
DBUG_RETURN(TRUE);
|
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
bool Alter_table_analyze_partition_statement::execute(THD *thd)
|
|
|
|
{
|
|
|
|
bool res;
|
|
|
|
DBUG_ENTER("Alter_table_analyze_partition_statement::execute");
|
|
|
|
|
|
|
|
/*
|
|
|
|
Flag that it is an ALTER command which administrates partitions, used
|
|
|
|
by ha_partition
|
|
|
|
*/
|
|
|
|
m_lex->alter_info.flags|= ALTER_ADMIN_PARTITION;
|
|
|
|
|
|
|
|
res= Analyze_table_statement::execute(thd);
|
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.
2010-10-06 11:34:28 -03:00
|
|
|
|
2010-08-16 14:53:30 +02:00
|
|
|
DBUG_RETURN(res);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
bool Alter_table_check_partition_statement::execute(THD *thd)
|
|
|
|
{
|
|
|
|
bool res;
|
|
|
|
DBUG_ENTER("Alter_table_check_partition_statement::execute");
|
|
|
|
|
|
|
|
/*
|
|
|
|
Flag that it is an ALTER command which administrates partitions, used
|
|
|
|
by ha_partition
|
|
|
|
*/
|
|
|
|
m_lex->alter_info.flags|= ALTER_ADMIN_PARTITION;
|
|
|
|
|
|
|
|
res= Check_table_statement::execute(thd);
|
|
|
|
|
|
|
|
DBUG_RETURN(res);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
bool Alter_table_optimize_partition_statement::execute(THD *thd)
|
|
|
|
{
|
|
|
|
bool res;
|
|
|
|
DBUG_ENTER("Alter_table_optimize_partition_statement::execute");
|
|
|
|
|
|
|
|
/*
|
|
|
|
Flag that it is an ALTER command which administrates partitions, used
|
|
|
|
by ha_partition
|
|
|
|
*/
|
|
|
|
m_lex->alter_info.flags|= ALTER_ADMIN_PARTITION;
|
|
|
|
|
|
|
|
res= Optimize_table_statement::execute(thd);
|
|
|
|
|
|
|
|
DBUG_RETURN(res);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
bool Alter_table_repair_partition_statement::execute(THD *thd)
|
|
|
|
{
|
|
|
|
bool res;
|
|
|
|
DBUG_ENTER("Alter_table_repair_partition_statement::execute");
|
|
|
|
|
|
|
|
/*
|
|
|
|
Flag that it is an ALTER command which administrates partitions, used
|
|
|
|
by ha_partition
|
|
|
|
*/
|
|
|
|
m_lex->alter_info.flags|= ALTER_ADMIN_PARTITION;
|
|
|
|
|
|
|
|
res= Repair_table_statement::execute(thd);
|
|
|
|
|
|
|
|
DBUG_RETURN(res);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
bool Alter_table_truncate_partition_statement::execute(THD *thd)
|
|
|
|
{
|
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.
2010-10-06 11:34:28 -03:00
|
|
|
int error;
|
|
|
|
ha_partition *partition;
|
|
|
|
ulong timeout= thd->variables.lock_wait_timeout;
|
2010-08-16 14:53:30 +02:00
|
|
|
TABLE_LIST *first_table= thd->lex->select_lex.table_list.first;
|
2010-12-03 10:33:29 +01:00
|
|
|
bool binlog_stmt;
|
2010-08-16 14:53:30 +02:00
|
|
|
DBUG_ENTER("Alter_table_truncate_partition_statement::execute");
|
|
|
|
|
|
|
|
/*
|
|
|
|
Flag that it is an ALTER command which administrates partitions, used
|
|
|
|
by ha_partition.
|
|
|
|
*/
|
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.
2010-10-06 11:34:28 -03:00
|
|
|
m_lex->alter_info.flags|= ALTER_ADMIN_PARTITION |
|
|
|
|
ALTER_TRUNCATE_PARTITION;
|
|
|
|
|
|
|
|
/* Fix the lock types (not the same as ordinary ALTER TABLE). */
|
|
|
|
first_table->lock_type= TL_WRITE;
|
|
|
|
first_table->mdl_request.set_type(MDL_EXCLUSIVE);
|
|
|
|
|
2010-08-16 14:53:30 +02:00
|
|
|
/*
|
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.
2010-10-06 11:34:28 -03:00
|
|
|
Check table permissions and open it with a exclusive lock.
|
|
|
|
Ensure it is a partitioned table and finally, upcast the
|
|
|
|
handler and invoke the partition truncate method. Lastly,
|
|
|
|
write the statement to the binary log if necessary.
|
2010-08-16 14:53:30 +02:00
|
|
|
*/
|
|
|
|
|
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.
2010-10-06 11:34:28 -03:00
|
|
|
if (check_one_table_access(thd, DROP_ACL, first_table))
|
|
|
|
DBUG_RETURN(TRUE);
|
2010-08-16 14:53:30 +02:00
|
|
|
|
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.
2010-10-06 11:34:28 -03:00
|
|
|
if (open_and_lock_tables(thd, first_table, FALSE, 0))
|
|
|
|
DBUG_RETURN(TRUE);
|
|
|
|
|
|
|
|
/*
|
|
|
|
TODO: Add support for TRUNCATE PARTITION for NDB and other
|
|
|
|
engines supporting native partitioning.
|
|
|
|
*/
|
2013-02-26 17:57:05 +05:30
|
|
|
|
|
|
|
if (!first_table->table || first_table->view ||
|
|
|
|
first_table->table->s->db_type() != partition_hton)
|
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.
2010-10-06 11:34:28 -03:00
|
|
|
{
|
|
|
|
my_error(ER_PARTITION_MGMT_ON_NONPARTITIONED, MYF(0));
|
|
|
|
DBUG_RETURN(TRUE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
Under locked table modes this might still not be an exclusive
|
|
|
|
lock. Hence, upgrade the lock since the handler truncate method
|
|
|
|
mandates an exclusive metadata lock.
|
|
|
|
*/
|
|
|
|
MDL_ticket *ticket= first_table->table->mdl_ticket;
|
|
|
|
if (thd->mdl_context.upgrade_shared_lock_to_exclusive(ticket, timeout))
|
|
|
|
DBUG_RETURN(TRUE);
|
|
|
|
|
|
|
|
tdc_remove_table(thd, TDC_RT_REMOVE_NOT_OWN, first_table->db,
|
|
|
|
first_table->table_name, FALSE);
|
|
|
|
|
|
|
|
partition= (ha_partition *) first_table->table->file;
|
|
|
|
|
|
|
|
/* Invoke the handler method responsible for truncating the partition. */
|
2010-12-01 22:47:40 +01:00
|
|
|
if ((error= partition->truncate_partition(&thd->lex->alter_info,
|
2010-12-03 10:33:29 +01:00
|
|
|
&binlog_stmt)))
|
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.
2010-10-06 11:34:28 -03:00
|
|
|
first_table->table->file->print_error(error, MYF(0));
|
|
|
|
|
|
|
|
/*
|
|
|
|
All effects of a truncate operation are committed even if the
|
|
|
|
operation fails. Thus, the query must be written to the binary
|
2010-12-01 22:47:40 +01:00
|
|
|
log. The exception is a unimplemented truncate method or failure
|
|
|
|
before any call to handler::truncate() is done.
|
|
|
|
Also, it is logged in statement format, regardless of the binlog format.
|
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.
2010-10-06 11:34:28 -03:00
|
|
|
*/
|
2010-12-03 10:33:29 +01:00
|
|
|
if (error != HA_ERR_WRONG_COMMAND && binlog_stmt)
|
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.
2010-10-06 11:34:28 -03:00
|
|
|
error|= write_bin_log(thd, !error, thd->query(), thd->query_length());
|
|
|
|
|
|
|
|
/*
|
|
|
|
A locked table ticket was upgraded to a exclusive lock. After the
|
|
|
|
the query has been written to the binary log, downgrade the lock
|
|
|
|
to a shared one.
|
|
|
|
*/
|
|
|
|
if (thd->locked_tables_mode)
|
|
|
|
ticket->downgrade_exclusive_lock(MDL_SHARED_NO_READ_WRITE);
|
|
|
|
|
|
|
|
if (! error)
|
|
|
|
my_ok(thd);
|
|
|
|
|
|
|
|
DBUG_RETURN(error);
|
2010-08-16 14:53:30 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* WITH_PARTITION_STORAGE_ENGINE */
|