The problem was that TRUNCATE TABLE didn't take a exclusive
lock on a table if it resorted to truncating via delete of
all rows in the table. Specifically for InnoDB tables, this
could break proper isolation as InnoDB ends up aborting some
granted locks when truncating a table.
The solution is to take a exclusive metadata lock before
TRUNCATE TABLE can proceed. This guarantees that no other
transaction is using the table.
Incompatible change: Truncate via delete no longer fails
if sql_safe_updates is activated (this was a undocumented
side effect).
------------------------------------------------------------
2599.161.3 Ingo Struewing 2009-07-21
Bug#20667 - Truncate table fails for a write locked table
TRUNCATE TABLE was not allowed under LOCK TABLES.
The patch removes this restriction. mysql_truncate()
does now handle that case.
revno: 2617.69.33
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-next-46452
timestamp: Wed 2009-08-19 18:39:31 +0400
message:
Bug#46452 "Crash in MDL, HANDLER OPEN + TRUNCATE TABLE".
Flush open HANDLER tables before TRUNCATE, which is a DDL.
Support of views wasn't implemented for the TRUNCATE statement.
Now TRUNCATE on views has the same semantics as DELETE FROM view:
mysql_truncate() checks whether the table is a view and falls back
to delete if so.
In order to initialize properly the LEX::updatable for a view
st_lex::can_use_merged() now allows usage of merged views for the
TRUNCATE statement.
Fixed problem with char > 128 in QUOTE() function. (Bug #1868)
Disable creation of symlinks if my_disable_symlink is set
Fixed searching of TEXT with end space. (Bug #1651)
Fixed caching bug in multi-table-update where same table was used twice. (Bug #1711)
Fixed problem with UNIX_TIMESTAMP() for timestamps close to 0. (Bug #1998)
Fixed timestamp.test
