replication aborts
When recieving a 'SLAVE STOP' command, slave SQL thread will roll back the
transaction and stop immidiately if there is only transactional table updated,
even through 'CREATE|DROP TEMPOARY TABLE' statement are in it. But These
statements can never be rolled back. Because the temporary tables to the user
session mapping remain until 'RESET SLAVE', Therefore it will abort SQL thread
with an error that the table already exists or doesn't exist, when it restarts
and executes the whole transaction again.
After this patch, SQL thread always waits till the transaction ends and then stops,
if 'CREATE|DROP TEMPOARY TABLE' statement are in it.
sql/sql_parse.cc:
Make some not commonly used functions with big local variables to separate functions to make default stack usage smaller.
Decrease size of db_buff[] (Was bigger than needed)
Allocate current_global_status_var with malloc().
storage/maria/ha_maria.cc:
Don't allocate HA_CHECK on stack (it's > 100K)
storage/maria/ma_check.c:
Removed duplicated code
discover its existence".
The problem was that user without any privileges on
routine was able to find out whether it existed or not.
DROP FUNCTION and DROP PROCEDURE statements were
checking if routine being dropped existed and reported
ER_SP_DOES_NOT_EXIST error/warning before checking
if user had enough privileges to drop it.
This patch solves this problem by changing code not to
check if routine exists before checking if user has enough
privileges to drop it. Moreover we no longer perform this
check using a separate call instead we rely on
sp_drop_routine() returning SP_KEY_NOT_FOUND if routine
doesn't exist.
This change also simplifies one of upcoming patches
refactoring global read lock implementation.
mysql-test/r/grant.result:
Updated test case after fixing bug#57061 "User without
privilege on routine can discover its existence". Removed
DROP PROCEDURE/FUNCTION statements which have started to
fail after this fix (correctly). There is no need in
dropping routines in freshly created database anyway.
mysql-test/r/sp-security.result:
Added new test case for bug#57061 "User without privilege
on routine can discover its existence". Updated existing
tests according to new behaviour.
mysql-test/suite/funcs_1/r/innodb_storedproc_06.result:
Updated test case after fixing bug#57061 "User without
privilege on routine can discover its existence".
Now we drop routines under user which has enough
privileges to do so.
mysql-test/suite/funcs_1/r/memory_storedproc_06.result:
Updated test case after fixing bug#57061 "User without
privilege on routine can discover its existence".
Now we drop routines under user which has enough
privileges to do so.
mysql-test/suite/funcs_1/r/myisam_storedproc_06.result:
Updated test case after fixing bug#57061 "User without
privilege on routine can discover its existence".
Now we drop routines under user which has enough
privileges to do so.
mysql-test/suite/funcs_1/storedproc/storedproc_06.inc:
Updated test case after fixing bug#57061 "User without
privilege on routine can discover its existence".
Now we drop routines under user which has enough
privileges to do so.
mysql-test/t/grant.test:
Updated test case after fixing bug#57061 "User without
privilege on routine can discover its existence". Removed
DROP PROCEDURE/FUNCTION statements which have started to
fail after this fix (correctly). There is no need in
dropping routines in freshly created database anyway.
mysql-test/t/sp-security.test:
Added new test case for bug#57061 "User without privilege
on routine can discover its existence". Updated existing
tests according to new behaviour.
sql/sp.cc:
Removed sp_routine_exists_in_table() which is no longer
used.
sql/sp.h:
Removed sp_routine_exists_in_table() which is no longer
used.
sql/sql_parse.cc:
When dropping routine we no longer check if routine exists
before checking if user has enough privileges to do so.
Moreover we no longer perform this check using a separate
call instead we rely on sp_drop_routine() returning
SP_KEY_NOT_FOUND if routine doesn't exist.
discover its existence".
The problem was that user without any privileges on
routine was able to find out whether it existed or not.
DROP FUNCTION and DROP PROCEDURE statements were
checking if routine being dropped existed and reported
ER_SP_DOES_NOT_EXIST error/warning before checking
if user had enough privileges to drop it.
This patch solves this problem by changing code not to
check if routine exists before checking if user has enough
privileges to drop it. Moreover we no longer perform this
check using a separate call instead we rely on
sp_drop_routine() returning SP_KEY_NOT_FOUND if routine
doesn't exist.
This change also simplifies one of upcoming patches
refactoring global read lock implementation.
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.
mysql-test/suite/innodb/t/innodb-truncate.test:
Add test cases for truncate and foreign key checks.
Also test that InnoDB resets auto-increment on truncate.
mysql-test/suite/innodb/t/innodb.test:
FK is not necessary, test is related to auto-increment.
Update error number, truncate is no longer invoked if
table is parent in a FK relationship.
mysql-test/suite/innodb/t/innodb_mysql.test:
Update error number, truncate is no longer invoked if
table is parent in a FK relationship.
Use delete instead of truncate, test is used to check
the interaction of FKs, triggers and delete.
mysql-test/suite/parts/inc/partition_check.inc:
Fix typo.
mysql-test/suite/sys_vars/t/foreign_key_checks_func.test:
Update error number, truncate is no longer invoked if
table is parent in a FK relationship.
mysql-test/t/mdl_sync.test:
Modify test case to reflect and ensure that truncate takes
a exclusive metadata lock.
mysql-test/t/trigger-trans.test:
Update error number, truncate is no longer invoked if
table is parent in a FK relationship.
sql/ha_partition.cc:
Reorganize the various truncate methods. delete_all_rows is now
passed directly to the underlying engines, so as truncate. The
code responsible for truncating individual partitions is moved
to ha_partition::truncate_partition, which is invoked when a
ALTER TABLE t1 TRUNCATE PARTITION p statement is executed.
Since the partition truncate no longer can be invoked via
delete, the bitmap operations are not necessary anymore. The
explicit reset of the auto-increment value is also removed
as the underlying engines are now responsible for reseting
the value.
sql/handler.cc:
Wire up the handler truncate method.
sql/handler.h:
Introduce and document the truncate handler method. It assumes
certain use cases of delete_all_rows.
Add method to retrieve the list of foreign keys referencing a
table. Method is used to avoid truncating tables that are
parent in a foreign key relationship.
sql/share/errmsg-utf8.txt:
Add error message for truncate and FK.
sql/sql_lex.h:
Introduce a flag so that the partition engine can detect when
a partition is being truncated. Used to give a special error.
sql/sql_parse.cc:
Function mysql_truncate_table no longer exists.
sql/sql_partition_admin.cc:
Implement the TRUNCATE PARTITION statement.
sql/sql_truncate.cc:
Change the truncate table implementation to use the new truncate
handler method and to not rely on row-by-row delete anymore.
The truncate handler method is always invoked with a exclusive
metadata lock. Also, it is no longer possible to truncate a
table that is parent in some non-self-referencing foreign key.
storage/archive/ha_archive.cc:
Rename method as the description indicates that in the future
this could be a truncate operation.
storage/blackhole/ha_blackhole.cc:
Implement truncate as no operation for the blackhole engine in
order to remain compatible with older releases.
storage/federated/ha_federated.cc:
Introduce truncate method that invokes delete_all_rows.
This is required to support partition truncate as this
form of truncate does not implement the drop and recreate
protocol.
storage/heap/ha_heap.cc:
Introduce truncate method that invokes delete_all_rows.
This is required to support partition truncate as this
form of truncate does not implement the drop and recreate
protocol.
storage/ibmdb2i/ha_ibmdb2i.cc:
Introduce truncate method that invokes delete_all_rows.
This is required to support partition truncate as this
form of truncate does not implement the drop and recreate
protocol.
storage/innobase/handler/ha_innodb.cc:
Rename delete_all_rows to truncate. InnoDB now does truncate
under a exclusive metadata lock.
Introduce and reorganize methods used to retrieve the list
of foreign keys referenced by a or referencing a table.
storage/myisammrg/ha_myisammrg.cc:
Introduce truncate method that invokes delete_all_rows.
This is required in order to remain compatible with earlier
releases where truncate would resort to a row-by-row delete.
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.
sql/field.cc:
Remove feature of 'new_mode' that was never implemtented in a newer MySQL version.
sql/item_cmpfunc.cc:
Boyer more is stable; Don't have to be protected by --skip-new anymore
sql/mysqld.cc:
Don't disable some proven stable functions with --skip-new
sql/records.cc:
Don't disable record caching with --safe-mode anymore
sql/sql_delete.cc:
Do fast truncate even if --skip-new or --safe is used
sql/sql_parse.cc:
Use always mysql_optimizer() for optimizer (instead of mysql_recreate_table() in case of --safe or --skip-new)
sql/sql_select.cc:
Don't disable 'only_eq_ref_tables' if --safe is used.
sql/sql_yacc.yy:
Removed not meaningfull test of --old
REPAIR of merge table
Bug #56422 CHECK TABLE run when the table is locked reports
corruption along with timeout
The crash happened if a table maintenance statement (ANALYZE TABLE,
REPAIR TABLE, etc.) was executed on a MERGE table and opening and
locking a child table failed. This could for example happen if a child
table did not exist or if a lock timeout happened while waiting for
a conflicting metadata lock to disappear.
Since opening and locking the MERGE table and its children failed,
the tables would be closed and the metadata locks released.
However, TABLE_LIST::table for the MERGE table would still be set,
with its value invalid since the tables had been closed.
This caused the table maintenance statement to try to continue
and upgrade the metadata lock on the MERGE table. But since the lock
already had been released, this caused a segfault.
This patch fixes the problem by setting TABLE_LIST::table to NULL
if open_and_lock_tables() fails. This prevents maintenance
statements from continuing and trying to upgrade the metadata lock.
The patch includes a 5.5 version of the fix for
Bug #46339 crash on REPAIR TABLE merge table USE_FRM.
This bug caused REPAIR TABLE ... USE_FRM to give an assert
when used on merge tables.
The patch also enables the CHECK TABLE statement for log tables.
Before, CHECK TABLE for log tables gave ER_CANT_LOCK_LOG_TABLE,
yet still counted the statement as successfully executed.
With the changes to table maintenance statement error handling
in this patch, CHECK TABLE would no longer be considered as
successful in this case. This would have caused upgrade scripts
to mistakenly think that the general and slow logs are corrupted
and have to be repaired. Enabling CHECK TABLES for log tables
prevents this from happening.
Finally, the patch changes the error message from "Corrupt" to
"Operation failed" for a number of issues not related to table
corruption. For example "Lock wait timeout exceeded" and
"Deadlock found trying to get lock".
Test cases added to merge.test and check.test.
REPAIR of merge table
Bug #56422 CHECK TABLE run when the table is locked reports
corruption along with timeout
The crash happened if a table maintenance statement (ANALYZE TABLE,
REPAIR TABLE, etc.) was executed on a MERGE table and opening and
locking a child table failed. This could for example happen if a child
table did not exist or if a lock timeout happened while waiting for
a conflicting metadata lock to disappear.
Since opening and locking the MERGE table and its children failed,
the tables would be closed and the metadata locks released.
However, TABLE_LIST::table for the MERGE table would still be set,
with its value invalid since the tables had been closed.
This caused the table maintenance statement to try to continue
and upgrade the metadata lock on the MERGE table. But since the lock
already had been released, this caused a segfault.
This patch fixes the problem by setting TABLE_LIST::table to NULL
if open_and_lock_tables() fails. This prevents maintenance
statements from continuing and trying to upgrade the metadata lock.
The patch includes a 5.5 version of the fix for
Bug #46339 crash on REPAIR TABLE merge table USE_FRM.
This bug caused REPAIR TABLE ... USE_FRM to give an assert
when used on merge tables.
The patch also enables the CHECK TABLE statement for log tables.
Before, CHECK TABLE for log tables gave ER_CANT_LOCK_LOG_TABLE,
yet still counted the statement as successfully executed.
With the changes to table maintenance statement error handling
in this patch, CHECK TABLE would no longer be considered as
successful in this case. This would have caused upgrade scripts
to mistakenly think that the general and slow logs are corrupted
and have to be repaired. Enabling CHECK TABLES for log tables
prevents this from happening.
Finally, the patch changes the error message from "Corrupt" to
"Operation failed" for a number of issues not related to table
corruption. For example "Lock wait timeout exceeded" and
"Deadlock found trying to get lock".
Test cases added to merge.test and check.test.
Don't do UNDO or REDO on a crashed table.
More DBUG_PRINT
sql/sql_parse.cc:
Remove display of 'packet' which is not useful
storage/maria/ma_blockrec.c:
More DBUG_PRINT()
storage/maria/ma_key_recover.c:
Write page number instead of page position
storage/maria/ma_recovery.c:
Write message to stderr if recovery is not likely to succeed because we don't log records for batch inserts.
In normal cases this should never be an issue as we would recreate an empty table if MariaDB dies under batch insert.
This warning will be given if you remove all tables and try to recreate them with maria_read_log, which can't be done as
the log doesn't contain all data.
Don't do UNDO or REDO on a crashed table.
storage/maria/ma_write.c:
Write page number instead of page position.
Fall back to use ALTER TABLE for engines that doesn't support REPAIR when doing repair for upgrade.
Nicer output from mysql_upgrade and mysql_check
Updated all arrays that used NAME_LEN to use SAFE_NAME_LEN to ensure that we don't break things accidently as names can now have a #mysql50# prefix.
client/mysql_upgrade.c:
If we are using verbose, also run mysqlcheck in verbose mode.
client/mysqlcheck.c:
Add more information if running in verbose mode
Print 'Needs upgrade' instead of complex error if table needs to be upgraded
Don't write connect information if verbose is not 2 or above
mysql-test/r/drop.result:
Updated test and results as we now support full table names
mysql-test/r/grant.result:
Now you get a correct error message if using #mysql with paths
mysql-test/r/show_check.result:
Update results as table names can temporarly be bigger than NAME_LEN (during upgrade)
mysql-test/r/upgrade.result:
Test upgrade for long table names.
mysql-test/suite/funcs_1/r/is_tables_is.result:
Updated old test result (had note been updated in a while)
mysql-test/t/drop.test:
Updated test and results as we now support full table names
mysql-test/t/grant.test:
Now you get a correct error message if using #mysql with paths
mysql-test/t/upgrade.test:
Test upgrade for long table names.
sql/ha_partition.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/item.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/log_event.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/mysql_priv.h:
Added SAFE_NAME_LEN
sql/rpl_filter.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sp.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sp_head.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_acl.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_base.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_connect.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_parse.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_prepare.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_select.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_show.cc:
NAME_LEN -> SAFE_NAME_LEN
Enlarge table names for SHOW TABLES to also include optional #mysql50#
sql/sql_table.cc:
Fall back to use ALTER TABLE for engines that doesn't support REPAIR when doing repair for upgrade.
sql/sql_trigger.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_udf.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/sql_view.cc:
NAME_LEN -> SAFE_NAME_LEN
sql/table.cc:
Fixed check_table_name() to not count #mysql50# as part of name
If #mysql50# is part of the name, don't allow path characters in name.
check_merge_table_access() used to do two things:
- set proper database for every merge table child;
- check SELECT | UPDATE | DELETE for merge table children.
Setting database is not needed anymore, since it's done
on the parsing stage.
Thus, check_merge_table_access() can be removed;
needed privileges can be checked using check_table_access().
check_merge_table_access() used to do two things:
- set proper database for every merge table child;
- check SELECT | UPDATE | DELETE for merge table children.
Setting database is not needed anymore, since it's done
on the parsing stage.
Thus, check_merge_table_access() can be removed;
needed privileges can be checked using check_table_access().
to allow temp table operations) -- prerequisite patch #2.
Introduce a new form of find_temporary_table() function:
find_temporary_table() by a table key. It will be used
in further patches.
Replace find_temporary_table(table_list->db, table_list->name)
by more appropiate find_temporary_table(table_list) across
the codebase.
to allow temp table operations) -- prerequisite patch #2.
Introduce a new form of find_temporary_table() function:
find_temporary_table() by a table key. It will be used
in further patches.
Replace find_temporary_table(table_list->db, table_list->name)
by more appropiate find_temporary_table(table_list) across
the codebase.
- Changed to still use bcmp() in certain cases becasue
- Faster for short unaligneed strings than memcmp()
- Bettern when using valgrind
- Changed to use my_sprintf() instead of sprintf() to get higher portability for old systems
- Changed code to use MariaDB version of select->skip_record()
- Removed -%::SCCS/s.% from Makefile.am:s to remove automake warnings
'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#47132, BUG#47442, BUG49494, BUG#23992 and BUG#48814 will disappear
automatically after the this patch.
BUG#55617 is fixed by this patch too.
This is the 5.5 part.
It implements:
- 'CREATE TABLE IF NOT EXISTS ... SELECT' statement will not insert
anything and binlog anything if the table already exists.
It only generate a warning that table already exists.
- A couple of test cases for the behavior changing.
'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#47132, BUG#47442, BUG49494, BUG#23992 and BUG#48814 will disappear
automatically after the this patch.
BUG#55617 is fixed by this patch too.
This is the 5.5 part.
It implements:
- 'CREATE TABLE IF NOT EXISTS ... SELECT' statement will not insert
anything and binlog anything if the table already exists.
It only generate a warning that table already exists.
- A couple of test cases for the behavior changing.
'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#55474, BUG#55499, BUG#55598, BUG#55616 and BUG#55777 are fixed
in this patch too.
This is the 5.1 part.
It implements:
- if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
and INSERT ... SELECT
- Insert nothing and binlog nothing on master if the existing object
is a view. It only generates a warning that table already exists.
mysql-test/r/trigger.result:
Ather this patch, 'CREATE TABLE IF NOT EXISTS ... SELECT' will not
insert anything if the creating table already exists and is a view.
sql/sql_class.h:
Declare virtual function write_to_binlog() for select_insert.
It's used to binlog 'create select'
sql/sql_insert.cc:
Implement write_to_binlog();
Use write_to_binlog() instead of binlog_query() to binlog the statement.
if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
and INSERT ... SELECT
sql/sql_lex.h:
Declare create_select_start_with_brace and create_select_pos.
They are helpful for binlogging 'create select'
sql/sql_parse.cc:
Do nothing on master if the existing object is a view.
sql/sql_yacc.yy:
Record the relative postion of 'SELECT' in the 'CREATE ...SELECT' statement.
Record whether there is a '(' before the 'SELECT' clause.
'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#55474, BUG#55499, BUG#55598, BUG#55616 and BUG#55777 are fixed
in this patch too.
This is the 5.1 part.
It implements:
- if the table exists, binlog two events: CREATE TABLE IF NOT EXISTS
and INSERT ... SELECT
- Insert nothing and binlog nothing on master if the existing object
is a view. It only generates a warning that table already exists.
locks on the table
Fixing the partitioning specifics after TRUNCATE TABLE in
bug-42643 was fixed.
Reorganize of code to decrease the size of the giant switch
in mysql_execute_command, and to prepare for future parser
reengineering. Moved code into Sql_statement objects.
Updated patch according to davi's review comments.
libmysqld/CMakeLists.txt:
Added new files.
libmysqld/Makefile.am:
Added new files.
mysql-test/r/not_partition.result:
now returning error on partitioning commands
if partitioning is not enabled.
mysql-test/r/partition_disabled.result:
There is no partition handlerton, so it cannot
find the specified engine in the .frm file.
mysql-test/r/partition_truncate.result:
Updated test results.
mysql-test/suite/parts/inc/partition_mgm.inc:
Added check that TRUNCATE PARTITION does not delete on failure.
mysql-test/suite/parts/r/partition_debug_sync_innodb.result:
updated results.
mysql-test/suite/parts/r/partition_mgm_lc0_archive.result:
updated results.
mysql-test/suite/parts/r/partition_mgm_lc1_archive.result:
updated results.
mysql-test/suite/parts/r/partition_mgm_lc2_archive.result:
updated results.
mysql-test/suite/parts/t/partition_debug_sync_innodb.test:
Test case for this bug.
mysql-test/t/not_partition.test:
Added check for TRUNCATE PARTITION without partitioning.
mysql-test/t/partition_truncate.test:
Added test of TRUNCATE PARTITION on non partitioned table.
sql/CMakeLists.txt:
Added new files.
sql/Makefile.am:
Added new files.
sql/datadict.cc:
Moved out the storage engine check into an own
function, including assert for lock.
sql/datadict.h:
added dd_frm_storage_engine.
sql/sql_alter_table.cc:
moved the code for SQLCOM_ALTER_TABLE in mysql_execute_command
into its own file, and using the Sql_statement object to
prepare for future parser reengineering.
sql/sql_alter_table.h:
Created Sql_statement object for ALTER TABLE.
sql/sql_lex.cc:
resetting m_stmt.
sql/sql_lex.h:
Temporary hack for forward declaration of enum_alter_table_change_level.
sql/sql_parse.cc:
Moved out ALTER/ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE
from the giant switch into their own Sql_statement
objects.
sql/sql_parse.h:
Exporting check_merge_table_access.
sql/sql_partition_admin.cc:
created Sql_statement for
ALTER TABLE t ANALYZE/CHECK/OPTIMIZE/REPAIR/TRUNCATE
PARTITION. To be able to reuse the TABLE equivalents.
sql/sql_partition_admin.h:
Added Sql_statement of partition admin statements.
sql/sql_table.cc:
Moved table maintenance code into sql_table_maintenance.cc
sql/sql_table.h:
Moved table maintenance code into sql_table_maintenance.h
exporting functions used by sql_table_maintenance.
sql/sql_table_maintenance.cc:
Moved table maintenance code from sql_table.cc
sql/sql_table_maintenance.h:
Sql_statement objects for ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE.
Also declaring the keycache functions.
sql/sql_truncate.cc:
Moved code from SQLCOM_TRUNCATE in mysql_execute_command into
Truncate_statement::execute.
Added check for partitioned table on TRUNCATE PARTITION.
Moved locking fix for partitioned table into
Alter_table_truncate_partition::execute.
sql/sql_truncate.h:
Truncate_statement declaration (sub class of Sql_statement).
sql/sql_yacc.yy:
Using the new Sql_statment objects.
locks on the table
Fixing the partitioning specifics after TRUNCATE TABLE in
bug-42643 was fixed.
Reorganize of code to decrease the size of the giant switch
in mysql_execute_command, and to prepare for future parser
reengineering. Moved code into Sql_statement objects.
Updated patch according to davi's review comments.
