- 09 Oct, 2008 3 commits
-
-
Sergey Glukhov authored
The problem was that PACK_KEYS and MAX_ROWS clause in ALTER TABLE did not trigger table reconstruction. The fix is to rebuild a table if PACK_KEYS or MAX_ROWS are specified. mysql-test/r/alter_table.result: test result mysql-test/t/alter_table.test: test case sql/sql_table.cc: The problem was that PACK_KEYS and MAX_ROWS clause in ALTER TABLE did not trigger table reconstruction. The fix is to rebuild a table if PACK_KEYS or MAX_ROWS are specified.
-
Sergey Glukhov authored
Hide "Table doesn't exist" errors if the table belongs to a merge table. mysql-test/r/merge.result: result fix mysql-test/t/merge.test: test case sql/sql_base.cc: Hide "Table doesn't exist" errors if the table belongs to a merge table.
-
Sergey Glukhov authored
The problem: table_open_method is not calculated properly if '*' is used in 'select' The fix: added table_open_method calculation for such case mysql-test/r/information_schema.result: test result mysql-test/t/information_schema.test: test case sql/sql_show.cc: The problem: table_open_method is not calculated properly if '*' is used in 'select' The fix: added table_open_method calculation for such case
-
- 08 Oct, 2008 3 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
The code to get read the value of a system variable was extracting its value on PREPARE stage and was substituting the value (as a constant) into the parse tree. Note that this must be a reversible transformation, i.e. it must be reversed before each re-execution. Unfortunately this cannot be reliably done using the current code, because there are other non-reversible source tree transformations that can interfere with this reversible transformation. Fixed by not resolving the value at PREPARE, but at EXECUTE (as the rest of the functions operate). Added a cache of the value (so that it's constant throughout the execution of the query). Note that the cache also caches NULL values. Updated an obsolete related test suite (variables-big) and the code to test the result type of system variables (as per bug 74). mysql-test/extra/rpl_tests/rpl_insert_id.test: Bug #32124: removed ambiguous testcase mysql-test/r/innodb_data_home_dir_basic.result: Bug #32124: fixed wrong test case mysql-test/r/innodb_flush_method_basic.result: Bug #32124: fixed wrong test case mysql-test/r/ps_11bugs.result: Bug #32124: test case mysql-test/r/ssl_capath_basic.result: Bug #32124: fixed wrong test case mysql-test/r/ssl_cipher_basic.result: Bug #32124: fixed wrong test case mysql-test/r/variables.result: Bug #32124: system vars are shown as such in EXPLAIN EXTENDED, not as constants. mysql-test/suite/rpl/r/rpl_insert_id.result: Bug #32124: removed ambiguous testcase mysql-test/t/ps_11bugs.test: Bug #32124: test case sql/item.cc: Bug #32124: placed the code to convert string to longlong or double to a function (so that it can be reused) sql/item.h: Bug #32124: placed the code to convert string to longlong or double to a function (so that it can be reused) sql/item_func.cc: Bug #32124: moved the evaluation of system variables at runtime (val_xxx). sql/item_func.h: Bug #32124: moved the evaluation of system variables at runtime (val_xxx). sql/set_var.cc: Bug #32124: removed the code that calculated the system variable's value at PREPARE sql/set_var.h: Bug #32124: removed the code that calculated the system variable's value at PREPARE tests/mysql_client_test.c: Bug #32124 : removed the reading of the system variable, because its max length is depended on the system charset and client charset and can't be easily calculated.
-
Marc Alff authored
-
- 07 Oct, 2008 10 commits
-
-
Marc Alff authored
-
Georgi Kodinov 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 19 commits
-
-
Marc Alff authored
warnings) Before this fix, several places in the code would raise a warning with an error code 0, making it impossible for a stored procedure, a connector, or a client application to trigger logic to handle the warning. Also, the warning text was hard coded, and therefore not translated. With this fix, new errors numbers have been created to represent these warnings, and the warning text is coded in the errmsg.txt file.
-
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.
-
Chad MILLER authored
-
Chad MILLER authored
-
Alexey Botchkov authored
-
Chad MILLER authored
-
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 options 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_state.result: Show that all log-related server variables that should throw deprecation warnings do, and the others don't. 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.
-
Alexey Botchkov authored
-
Mattias Jonsson authored
-
Alexey Botchkov authored
problems are located in the sql_partition.cc where functions calculation partition_id don't expect error returned from item->val_int(). Fixed by adding checks to these functions. Note - it tries to fix more problems than just the reported bug. per-file comments: modified: mysql-test/r/partition.result Bug#38083 Error-causing row inserted into partitioned table despite error test result mysql-test/t/partition.test Bug#38083 Error-causing row inserted into partitioned table despite error test case sql/opt_range.cc Bug#38083 Error-causing row inserted into partitioned table despite error get_part_id() call fixed sql/partition_info.h Bug#38083 Error-causing row inserted into partitioned table despite error get_subpart_id_func interface changed. sql/sql_partition.cc Bug#38083 Error-causing row inserted into partitioned table despite error various functions calculationg partition_id and subpart_id didn't expect an error returned from item->val_int(). Error checks added.
-
- 04 Oct, 2008 2 commits
-
-
Matthias Leich authored
with actual tree
-
Matthias Leich authored
(no conflicts)
-
- 03 Oct, 2008 3 commits
-
-
Chad MILLER authored
-
Chad MILLER authored
-
Mattias Jonsson authored
-