- 07 Nov, 2008 2 commits
-
-
Joerg Bruehe authored
and fix a defect specific to 5.1 (wrong quoting). support-files/mysql.spec.sh: Merge the general flag handling (embedding in blanks) from 5.0 to 5.1, add the 5.1 specific part (do not escape unquoted quote marks). Still part of the fix for bug#40546.
-
Joerg Bruehe authored
Fix yesterday's patch so that it also works for the last flag. Still part of the fix for bug#40546. support-files/mysql.spec.sh: The original "sed" command relied on a blank following the flag which should be removed for debug builds. This meant the last flag would not be matched. Change it so that the whole string is enclosed in blanks, demand leading and trailing blank for each flag, and finally strip the leading + trailing blank.
-
- 06 Nov, 2008 2 commits
-
-
Joerg Bruehe authored
Prevent this by modifying CFLAGS and CXXFLAGS. Upmerge from 5.0, modified according to the different spec file structure. support-files/mysql.spec.sh: Bug #40546 Debug server in RPM is built with compiler optimization Modify CFLAGS and CXXFLAGS for the duration of the debug server build (implemented by doing it in a subshell) so that they do not contain any optimization flag. Play it safe and prepare for both gcc and icc.
-
Joerg Bruehe authored
Prevent this by modifying CFLAGS and CXXFLAGS. support-files/mysql.spec.sh: Bug #40546 Debug server in RPM is built with compiler optimization Modify CFLAGS and CXXFLAGS for the duration of the debug server build (implemented by doing it in a subshell) so that they do not contain any optimization flag. Play it safe and prepare for both gcc and icc.
-
- 09 Oct, 2008 4 commits
-
-
Gleb Shchepa authored
-
Gleb Shchepa authored
derived table cause crash When a multi-UPDATE command fails to lock some table, and subsequently succeeds, the tables need to be reopened if they were altered. But the reopening procedure failed for derived tables. Extra cleanup has been added. mysql-test/r/lock_multi.result: Added test case for bug #38499. mysql-test/t/lock_multi.test: Added test case for bug #38499. sql/sql_union.cc: Bug#38499: flush tables and multitable table update with derived table cause crash Obsolete assertion has been removed. sql/sql_update.cc: Bug#38499: flush tables and multitable table update with derived table cause crash Extra cleanup for derived tables has been added: 1) unit.cleanup(), 2) unit->reinit_exec_mechanism().
-
Georgi Kodinov authored
-
Georgi Kodinov authored
Fixed a compilation warning
-
- 08 Oct, 2008 10 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Ramil Kalimullin authored
upgrade from <=5.0.46 to >=5.0.48 Problem: 'check table .. for upgrade' doesn't detect incompatible collation changes made in 5.0.48. Fix: check for incompatible collation changes. sql/handler.cc: Fix for bug#39585: innodb and myisam corruption after binary upgrade from <=5.0.46 to >=5.0.48 - check for incompatible collation changes made in 5.0.48: bug #29461 latin7_general_ci latin7_general_cs latin7_estonian_cs latin2_hungarian_ci koi8u_general_ci cp1251_ukrainian_ci cp1250_general_ci bug #29499, bug #27562 ascii_general_ci
-
Mats Kindahl authored
-
Georgi Kodinov authored
-
Mats Kindahl authored
The failure was caused by executing a CREATE-SELECT statement that creates a table in another database than the current one. In row-based logging, the CREATE statement was written to the binary log without the database, hence creating the table in the wrong database, causing the following inserts to fail since the table didn't exist in the given database. Fixed the bug by adding a parameter to store_create_info() that will make the function print the database name before the table name and used that in the calls that write the CREATE statement to the binary log. The database name is only printed if it is different than the currently selected database. The output of SHOW CREATE TABLE has not changed and is still printed without the database name. mysql-test/suite/rpl/t/rpl_row_create_table.test: Added test to check that CREATE-SELECT into another database than the current one replicates. sql/sql_insert.cc: Adding parameter to calls to store_create_info(). sql/sql_show.cc: Adding parameter to calls to store_create_info(). Extending store_create_info() with parameter 'show_database' that will cause the database to be written before the table name. sql/sql_show.h: Adding parameter to call to store_create_info() to tell if the database should be shown or not. sql/sql_table.cc: Adding parameter to calls to store_create_info().
-
Georgi Kodinov authored
disabled a randomly failing test and opened a bug report
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Mattias Jonsson authored
InnoDB Plugin locks table This is a pre fix update that does the change to the handler api. This is done since there are already changes in this version, so the real fix does not need to change the api. sql/handler.h: Bug#37453: Dropping/creating index on partitioned table with InnoDB Plugin locks table The check for which alter table flags a handler have is done through the handlerton, which will not work correctly for any partitioned table. It must be through the handler interface. To be able to fix this I have to add a virtual function to the handler class.
-
- 07 Oct, 2008 12 commits
-
-
Gleb Shchepa authored
-
Gleb Shchepa authored
``FLUSH TABLES WITH READ LOCK'' Concurrent execution of 1) multitable update with a NATURAL/USING join and 2) a such query as "FLUSH TABLES WITH READ LOCK" or "ALTER TABLE" of updating table led to a server crash. The mysql_multi_update_prepare() function call is optimized to lock updating tables only, so it postpones locking to the last, and if locking fails, it does cleanup of modified syntax structures and repeats a query analysis. However, that cleanup procedure was incomplete for NATURAL/USING join syntax data: 1) some Field_item items pointed into freed table structures, and 2) the TABLE_LIST::join_columns fields was not reset. Major change: short-living Field *Natural_join_column::table_field has been replaced with long-living Item*. mysql-test/r/lock_multi.result: Added test case for bug #38691. mysql-test/t/lock_multi.test: Added test case for bug #38691. sql/item.cc: Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while ``FLUSH TABLES WITH READ LOCK'' The Item_field constructor has been modified to allocate and copy original database/table/field names always (not during PS preparation/1st execution only), because an initialization of Item_field items with a pointer to short-living Field structures is a common practice. sql/sql_base.cc: Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while ``FLUSH TABLES WITH READ LOCK'' 1) Type adjustment for Natural_join_column::table_field (Field to Item_field); 2) The setup_natural_join_row_types function has been updated to take into account new first_natural_join_processing flag to skip unnecessary reinitialization of Natural_join_column::join_columns during table reopening after lock_tables() failure (like the 'first_execution' flag for PS). sql/sql_lex.cc: Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while ``FLUSH TABLES WITH READ LOCK'' Initialization of the new st_select_lex::first_natural_join_processing flag has been added. sql/sql_lex.h: Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while ``FLUSH TABLES WITH READ LOCK'' The st_select_lex::first_natural_join_processing flag has been added to skip unnecessary rebuilding of NATURAL/USING JOIN structures during table reopening after lock_tables failure. sql/sql_update.cc: Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while ``FLUSH TABLES WITH READ LOCK'' Extra cleanup calls have been added to reset Natural_join_column::table_field items. sql/table.cc: Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while ``FLUSH TABLES WITH READ LOCK'' Type adjustment for Natural_join_column::table_field (Field to Item_field). sql/table.h: Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while ``FLUSH TABLES WITH READ LOCK'' Type of the Natural_join_column::table_field field has been changed from Field that points into short-living TABLE memory to long-living Item_field that can be linked to (fixed) reopened table.
-
Georgi Kodinov authored
-
Gleb Shchepa authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Ramil Kalimullin authored
ha_statistic_increment for rpl_temporary Problem: in some cases master send a special event to reconnecting slave to keep slave's temporary tables (see #17284) and they still have references to the "old" SQL slave thread and use them to access thread's data. Fix: set temporary tables thread references to the actual SQL slave thread in such cases. mysql-test/suite/rpl/t/disabled.def: Fix for bug#38269: pushbuild gives valgrind error in ha_statistic_increment for rpl_temporary - rpl_temporary test enabled. sql/log_event.cc: Fix for bug#38269: pushbuild gives valgrind error in ha_statistic_increment for rpl_temporary - if we keep slave's temporary tables after reconnect, set their thread pointers (->in_use) to the current SQL thread.
-
Georgi Kodinov authored
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
Georgi Kodinov authored
-
- 06 Oct, 2008 10 commits
-
-
Guilhem Bichot authored
-
Chad MILLER authored
-
Chad MILLER authored
so that if the substitution contains single-quotes, the program will fail.
-
Tatiana A. Nurnberg authored
Adds --general-log-file, --slow-query-log-file command- line options to match system variables of the same names. Deprecates --log, --log-slow-queries command-line option and log, log_slow_queries system-variables for v7.0; they are superseded by general_log/general_log_file and slow_query_log/slow_query_log_file, respectively. mysql-test/r/log_basic.result: Change deprecated system variable "log" to general log. mysql-test/r/log_bin_trust_routine_creators_basic.result: Change deprecation warning so it's more obvious we're referring to a variable. mysql-test/r/log_state.result: Show that all log-related server variables that should throw deprecation warnings do, and the others don't. mysql-test/r/warnings.result: Change deprecation warning so it's more obvious we're referring to a variable. mysql-test/suite/rpl/r/rpl_sp.result: Change deprecation warning so it's more obvious we're referring to a variable. mysql-test/t/log_basic.test: Change deprecated system variable "log" to general log. mysql-test/t/log_state.test: Show that all log-related server variables that should throw deprecation warnings do, and the others don't. sql/mysqld.cc: Add command-line options --general-log-file and --slow-query-log-file to match server options of the same name. Deprecated --log and --log-slow-queries command-line options; they are superseded by --general-log/ --general-log-file and --slow-query-log/--slow-query-log-file, respectively sql/set_var.cc: Deprecate system-variables log in favour of general_log, log_slow_queries in favour of slow_query_log for 7.0, both for value- and DEFAULT-setting.
-
Guilhem Bichot authored
"Trigger fired multiple times leads to gaps in auto_increment sequence". The bug was that if a trigger fired multiple times inside a top statement (for example top-statement is a multi-row INSERT, and trigger is ON INSERT), and that trigger inserted into an auto_increment column, then gaps could be observed in the auto_increment sequence, even if there were no other users of the database (no concurrency). It was wrong usage of THD::auto_inc_intervals_in_cur_stmt_for_binlog. Note that the fix changes "class handler", I'll tell the Storage Engine API team. mysql-test/r/trigger-trans.result: result; before the bugfix, the sequence was 1,2,4,6,8,10,12... mysql-test/t/trigger-trans.test: test for BUG#31612 sql/handler.cc: See revision comment of handler.h. As THD::auto_inc_intervals_in_cur_stmt_for_binlog is cumulative over all trigger invokations by the top statement, the second invokation of the trigger arrived in handler::update_auto_increment() with already one interval in THD::auto_inc_intervals_in_cur_stmt_for_binlog. The method thus believed it had already reserved one interval for that invokation, thus reserved a twice larger interval (heuristic when we don't know how large the interval should be: we grow by powers of two). InnoDB thus increased its internal per-table auto_increment counter by 2 while only one row was to be inserted. Hence a gap in the sequence. The fix is to use the new handler::auto_inc_intervals_count. Note that the trigger's statement knows how many rows it is going to insert, but provides estimation_rows_to_insert == 0 (see comments in sql_insert.cc why triggers don't call handler::ha_start_bulk_insert()). * removing white space at end of line * we don't need to maintain THD::auto_inc_intervals_in_cur_stmt_for_binlog if no binlogging or if row-based binlogging. Using auto_inc_intervals_count in the heuristic makes the heuristic independent of binary logging, which is good. sql/handler.h: THD::auto_inc_intervals_in_cur_stmt_for_binlog served - for binlogging - as a heuristic when we have no estimation of how many records the statement will insert. But the first goal needs to be cumulative over all statements which form a binlog event, while the second one needs to be attached to each statement. THD::auto_inc_intervals_in_cur_stmt_for_binlog is cumulative, leading to BUG#31612. So we introduce handler::auto_inc_intervals_count for the second goal. See the revision comment of handler.cc. A smaller issue was that, even when the binlog event was only one statement (no triggers, no stored functions), THD::auto_inc_intervals_in_cur_stmt.nb_elements() could be lower than the number of reserved intervals (fooling the heuristic), because its append() method collapses two contiguous intervals in one. Note that as auto_inc_intervals_count is in class 'handler' and not in class 'THD', it does not need to be handled in THD::reset|restore_sub_statement_state(). sql/log.cc: Comment is wrong: if auto_increment is second, in handler::update_auto_increment() 'append' is false and so auto_inc_intervals_in_cur_stmt_for_binlog is empty, we do not come here. sql/sql_class.h: comment
-
Chad MILLER authored
-
Chad MILLER authored
-
Chad MILLER authored
-
Alexey Botchkov authored
-
Alexey Botchkov authored
MyISAM blocks index usage for bulk insert into zero-records tables. See ha_myisam::start_bulk_insert() lines from ... if (file->state->records == 0 ... ... That causes problems for partition engine when some partitions have records some not as the engine uses same access method for all partitions. Now partition engine doesn't call index_first/index_last for empty tables. per-file comments: mysql-test/r/partition.result Bug#38005 Partitions: error with insert select. test result mysql-test/t/partition.test Bug#38005 Partitions: error with insert select. test case sql/ha_partition.cc Bug#38005 Partitions: error with insert select. ha_engine::index_first and ha_engine::index_last not called for empty tables.
-