Attempts to execute RESET statements within a transaction that
had acquired metadata locks, led to an assertion failure on
debug servers. This bug didn't cause any problems on release
builds.
The triggered assert is designed to check that caches are not
flushed or reset while having active transactions. It is triggered
if acquired metadata locks exist that are not from LOCK TABLE or
HANDLER statements.
In this case it was triggered by RESET QUERY CACHE while having
an active transaction that had acquired locks. The reason the
assertion was triggered, was that RESET statements, unlike the
similar FLUSH statements, was not causing an implicit commit.
This patch fixes the problem by making sure RESET statements
commit the current transaction before executing. The commit
causes acquired metadata locks to be released, preventing the
assertion from being triggered.
Incompatible change: This patch changes RESET statements so
that they cause an implicit commit.
Test case added to query_cache.test.
------------------------------------------------------------
revno: 2630.13.16
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: WL#4284
timestamp: Sat 2008-07-26 13:38:20 -0300
message:
WL#4284: Transactional DDL locking
SQL statements' effect on transactions.
Currently the MySQL server and its storage engines are not
capable of rolling back operations that define or modify data
structures (also known as DDL statements) or operations that
alter any of the system tables (the mysql database). Allowing
these group of statements to participate in transactions
is unfeasible at this time (since rollback has no effect
whatsoever on them) and goes against the design of our metadata
locking subsystem.
The solution is to issue implicit commits before and after
those statements execution. This effectively confines each of
those statements to its own special transaction and ensures
that metadata locks taken during this special transaction
are not leaked into posterior statements/transactions.
mysql-test/include/commit.inc:
Alter table rename was not committing the normal transaction at the
end of its execution, and as a consequence, the commit was being
issued in the next DDL command (rename table) that happened to end
the active transaction. Other changes are to take into account the
implicit commits issued before and after the DDL command execution.
mysql-test/include/implicit_commit_helper.inc:
Add auxiliary test that shows if a statement issued a
implicit commit.
mysql-test/r/commit_1innodb.result:
Update test case result.
mysql-test/r/implicit_commit.result:
Test implicit commit behavior of some SQL commands.
mysql-test/t/implicit_commit.test:
Test implicit commit behavior of some SQL commands.
sql/events.cc:
Transaction is now ended before the command execution.
sql/mysql_priv.h:
Add flags array for server commands and remove historical
left over.
sql/sql_class.h:
Add flags to control when to issue implicit commits before and
after a command execution.
sql/sql_delete.cc:
A implicit commit is issued at the end of truncate
statements.
sql/sql_parse.cc:
Mark commands that need implicit commits before and
after their executions. The implicit commits of the
statement and the normal transaction are now issued
regardless of the user access privileges.
sql/sql_table.cc:
A implicit commit is now issued before admin commands.
tests/mysql_client_test.c:
Test that COM_REFRESH issues a implicit commit.
