- 02 Sep, 2009 1 commit
-
-
Sergey Vojtovich authored
extraneous file Online/fast ALTER TABLE of a partitioned table may leave temporary file in database directory. Fixed by removing unnecessary call to handler::ha_create_handler_files(), which was creating partitioning definition file. mysql-test/r/partition_innodb.result: A test case for BUG#46483. mysql-test/t/partition_innodb.test: A test case for BUG#46483. sql/unireg.cc: Do not call ha_create_handler_files() when we were requested to create only dot-frm file.
-
- 31 Aug, 2009 1 commit
-
-
unknown authored
Update the test case for BUG#44331 to fix the push build failure.
-
- 30 Aug, 2009 3 commits
-
-
Staale Smedseng authored
-
Alexey Kopytov authored
-
Alexey Kopytov authored
results in server crash check_group_min_max_predicates() assumed the input condition item to be one of COND_ITEM, SUBSELECT_ITEM, or FUNC_ITEM. Since a condition of the form "field" is also a valid condition equivalent to "field <> 0", using such a condition in a query where the loose index scan was chosen resulted in a debug assertion failure. Fixed by handling conditions of the FIELD_ITEM type in check_group_min_max_predicates(). mysql-test/r/group_min_max.result: Added a test case for bug #46607. mysql-test/t/group_min_max.test: Added a test case for bug #46607. sql/opt_range.cc: Handle conditions of the FUNC_ITEM type in check_group_mix_max_predicates().
-
- 29 Aug, 2009 1 commit
-
-
unknown authored
If an EVENT is created without the DEFINER clause set explicitly or with it set to CURRENT_USER, the master and slaves become inconsistent. This issue stems from the fact that in both cases, the DEFINER is set to the CURRENT_USER of the current thread. On the master, the CURRENT_USER is the mysqld's user, while on the slave, the CURRENT_USER is empty for the SQL Thread which is responsible for executing the statement. To fix the problem, we do what follows. If the definer is not set explicitly, a DEFINER clause is added when writing the query into binlog; if 'CURRENT_USER' is used as the DEFINER, it is replaced with the value of the current user before writing to binlog. mysql-test/suite/rpl/r/rpl_create_if_not_exists.result: Updated the result file after fixing bug#44331 mysql-test/suite/rpl/r/rpl_drop_if_exists.result: Updated the result file after fixing bug#44331 mysql-test/suite/rpl/r/rpl_events.result: Test result of Bug#44331 mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result: Updated the result file after fixing bug#44331 mysql-test/suite/rpl/t/rpl_events.test: Added test to verify if the definer is consistent between master and slave when the event is created without the DEFINER clause set explicitly or the DEFINER is set to CURRENT_USER sql/events.cc: The "create_query_string" function is added to create a new query string for removing executable comments. sql/sql_yacc.yy: The remember_name token was added for recording the offset of EVENT_SYM.
-
- 28 Aug, 2009 8 commits
-
-
Davi Arnaut authored
mysql-test/r/lock_multi_bug38499.result: Update test case result. mysql-test/r/lock_multi_bug38691.result: Update test case result. mysql-test/t/lock_multi_bug38499.test: Do not sync .frm files. mysql-test/t/lock_multi_bug38691.test: Do not sync .frm files.
-
Staale Smedseng authored
-
Staale Smedseng authored
with gcc 4.3.2 This patch fixes a number of GCC warnings about variables used before initialized. A new macro UNINIT_VAR() is introduced for use in the variable declaration, and LINT_INIT() usage will be gradually deprecated. (A workaround is used for g++, pending a patch for a g++ bug.) GCC warnings for unused results (attribute warn_unused_result) for a number of system calls (present at least in later Ubuntus, where the usual void cast trick doesn't work) are also fixed. client/mysqlmanager-pwgen.c: A fix for warn_unused_result, adding fallback to use of srand()/rand() if /dev/random cannot be used. Also actually adds calls to rand() in the second branch so that it actually creates a random password.
-
Davi Arnaut authored
client/mysql.cc: Remove leading whitespace. Remove extra text after #else directive. client/mysqldump.c: Function does not take a parameter. mysys/array.c: buffer is a uchar pointer. sql/item.cc: Assert if it should not happen. storage/myisam/mi_check.c: Cast to expected type. This is probably a bug, but it is casted in a similar way in another part of the code. storage/ndb/include/mgmapi/ndb_logevent.h: Apply fix from cluster team. tests/mysql_client_test.c: Remove extraneous slash.
-
Mattias Jonsson authored
-
Mattias Jonsson authored
sql/opt_range.cc: Removed duplicate code (if statement must have been duplicated during earlier merge). sql/sql_partition.cc: After mergeing bug#46362 and bug#20577, the NULL partition was also searched when col = const, fixed by checking if = or range.
-
Alfranio Correia authored
-
Alfranio Correia authored
-
- 27 Aug, 2009 6 commits
-
-
Alfranio Correia authored
When a connection is dropped any remaining temporary table is also automatically dropped and the SQL statement of this operation is written to the binary log in order to drop such tables on the slave and keep the slave in sync. Specifically, the current code base creates the following type of statement: DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `db`.`table`; Unfortunately, appending the database to the table name in this manner circumvents the replicate-rewrite-db option (and any options that check the current database). To solve the issue, we started writing the statement to the binary as follows: use `db`; DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `table`;
-
Alfranio Correia authored
Slave does not correctly handle "expected errors" leading to inconsistencies between the mater and slave. Specifically, when a statement changes both transactional and non-transactional tables, the transactional changes are automatically rolled back on the master but the slave ignores the error and does not roll them back thus leading to inconsistencies. To fix the problem, we automatically roll back a statement that fails on the slave but note that the transaction is not rolled back unless a "rollback" command is in the relay log file. mysql-test/extra/rpl_tests/rpl_mixing_engines.test: Enabled item 13.e which was disabled because of the bug fixed by the current and removed item 14 which was introduced by mistake.
-
Sergey Glukhov authored
-
Sergey Glukhov authored
The crash happens because select_union object is used as result set for queries which have derived tables. select_union use temporary table as data storage and if fields count exceeds 10(count of values for procedure ANALYSE()) then we get a crash on fill_record() function. mysql-test/r/analyse.result: test result mysql-test/r/subselect.result: result fix mysql-test/t/analyse.test: test case mysql-test/t/subselect.test: test fix sql/sql_yacc.yy: The crash happens because select_union object is used as result set for queries which have derived tables. select_union use temporary table as data storage and if fields count exceeds 10(count of values for procedure ANALYSE()) then we get a crash on fill_record() function.
-
Alfranio Correia authored
Updated main.mysqlbinlog_row_trans's result file as TRUNCATE statements are wrapped in BEGIN...COMMIT.
-
Georgi Kodinov authored
-
- 26 Aug, 2009 5 commits
-
-
Alfranio Correia authored
binlog Mixing transactional (T) and non-transactional (N) tables on behalf of a transaction may lead to inconsistencies among masters and slaves in STATEMENT mode. The problem stems from the fact that although modifications done to non-transactional tables on behalf of a transaction become immediately visible to other connections they do not immediately get to the binary log and therefore consistency is broken. Although there may be issues in mixing T and M tables in STATEMENT mode, there are safe combinations that clients find useful. In this bug, we fix the following issue. Mixing N and T tables in multi-level (e.g. a statement that fires a trigger) or multi-table table statements (e.g. update t1, t2...) were not handled correctly. In such cases, it was not possible to distinguish when a T table was updated if the sequence of changes was N and T. In a nutshell, just the flag "modified_non_trans_table" was not enough to reflect that both a N and T tables were changed. To circumvent this issue, we check if an engine is registered in the handler's list and changed something which means that a T table was modified. Check WL 2687 for a full-fledged patch that will make the use of either the MIXED or ROW modes completely safe. mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT. mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Truncate statement is wrapped in BEGIN/COMMIT.
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
Problem was that the partition containing NULL values was pruned away, since '2001-01-01' < '2001-02-00' but TO_DAYS('2001-02-00') is NULL. Added the NULL partition for RANGE/LIST partitioning on TO_DAYS() function to be scanned too. Also fixed a bug that added ALLOW_INVALID_DATES to sql_mode (SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST partitioned table would add it). mysql-test/include/partition_date_range.inc: Bug#20577: Partitions: use of to_days() function leads to selection failures Added include file to decrease test code duplication mysql-test/r/partition_pruning.result: Bug#20577: Partitions: use of to_days() function leads to selection failures Added test results mysql-test/r/partition_range.result: Bug#20577: Partitions: use of to_days() function leads to selection failures Updated test result. This fix adds the partition containing NULL values to the list of partitions to be scanned. mysql-test/t/partition_pruning.test: Bug#20577: Partitions: use of to_days() function leads to selection failures Added test case sql/item.h: Bug#20577: Partitions: use of to_days() function leads to selection failures Added MONOTONIC_*INCREASE_NOT_NULL values to be used by TO_DAYS. sql/item_timefunc.cc: Bug#20577: Partitions: use of to_days() function leads to selection failures Calculate the number of days as return value even for invalid dates. This is so that pruning can be used even for invalid dates. sql/opt_range.cc: Bug#20577: Partitions: use of to_days() function leads to selection failures Fixed a bug that added ALLOW_INVALID_DATES to sql_mode (SELECT * FROM t WHERE date_col < '1999-99-99' on a RANGE/LIST partitioned table would add it). sql/partition_info.h: Bug#20577: Partitions: use of to_days() function leads to selection failures Resetting ret_null_part when a single partition is to be used, this to avoid adding the NULL partition. sql/sql_partition.cc: Bug#20577: Partitions: use of to_days() function leads to selection failures Always include the NULL partition if RANGE or LIST. Use the returned value for the function for pruning, even if it is marked as NULL, so that even '2000-00-00' can be used for pruning, even if TO_DAYS('2000-00-00') is NULL. Changed == to >= in get_next_partition_id_list to avoid crash if part_iter->part_nums is not correctly setup.
-
Mattias Jonsson authored
There were a problem since pruning uses the field for comparison (while evaluate_join_record uses longlong), resulting in pruning failures when comparing DATE to DATETIME. Fix was to always comparing DATE vs DATETIME as DATETIME, by adding ' 00:00:00' to the DATE string. And adding optimization for comparing with 23:59:59, so that DATETIME_col > '2001-02-03 23:59:59' -> TO_DAYS(DATETIME_col) > TO_DAYS('2001-02-03 23:59:59') instead of '>='. mysql-test/r/partition_pruning.result: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) Updated result-file mysql-test/t/partition_pruning.test: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) Added testcases. sql-common/my_time.c: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) removed duplicate assignment. sql/item.cc: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) Changed field_is_equal_to_item into field_cmp_to_item, to better handling DATE vs DATETIME comparision. sql/item.h: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) Updated comment sql/item_timefunc.cc: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) Added optimization (pruning) of DATETIME where time-part is 23:59:59 sql/opt_range.cc: Bug#46362: Endpoint should be set to false for TO_DAYS(DATE) Using the new stored_field_cmp_to_item for better pruning.
-
- 24 Aug, 2009 4 commits
-
-
Davi Arnaut authored
The problem was that creating a DECIMAL column from a decimal value could lead to a failed assertion as decimal values can have a higher precision than those attached to a table. The assert could be triggered by creating a table from a decimal with a large (> 30) scale. Also, there was a problem in calculating the number of digits in the integral and fractional parts if both exceeded the maximum number of digits permitted by the new decimal type. The solution is to ensure that truncation procedure is executed when deducing a DECIMAL column from a decimal value of higher precision. If the integer part is equal to or bigger than the maximum precision for the DECIMAL type (65), the integer part is truncated to fit and the fractional becomes zero. Otherwise, the fractional part is truncated to fit into the space left after the integer part is copied. This patch borrows code and ideas from Martin Hansson's patch. mysql-test/r/type_newdecimal.result: Add test case result for Bug#45261. Also, update test case to reflect that an additive operation increases the precision of the resulting type by 1. mysql-test/t/type_newdecimal.test: Add test case for Bug#45261 sql/field.cc: Added DBUG_ASSERT to ensure object's invariant is maintained. Implement method to create a field to hold a decimal value from an item. sql/field.h: Explain member variable. Add method to create a new decimal field. sql/item.cc: The precision should only be capped when storing the value on a table. Also, this makes it impossible to calculate the integer part if Item::decimals (the scale) is larger than the precision. sql/item.h: Simplify calculation of integer part. sql/item_cmpfunc.cc: Do not limit the precision. It will be capped later. sql/item_func.cc: Use new method for allocating a new decimal field. Add a specialized method for retrieving the precision of a user variable item. sql/item_func.h: Add method to return the precision of a user variable. sql/item_sum.cc: Use new method for allocating a new decimal field. sql/my_decimal.h: The integer part could be improperly calculated for a decimal with 31 digits in the fractional part. sql/sql_select.cc: Use new method which truncates the integer or decimal parts as needed.
-
Georgi Kodinov authored
The code was using a special global buffer for the value of IS NULL ranges. This was not always long enough to be copied by a regular memcpy. As a result read buffer overflows may occur. Fixed by setting the null byte to 1 and setting the rest of the field disk image to NULL with a bzero (instead of relying on the buffer and memcpy()).
-
Alfranio Correia authored
-
Alfranio Correia authored
-
- 21 Aug, 2009 8 commits
-
-
Mattias Jonsson authored
-
Mattias Jonsson authored
INSERT ... SELECT ... Problem was that when bulk insert is used on an empty table/partition, it disables the indexes for better performance, but in this specific case it also tries to read from that partition using an index, which is not possible since it has been disabled. Solution was to allow index reads on disabled indexes if there are no records. Also reverted the patch for bug#38005, since that was a workaround in the partitioning engine instead of a fix in myisam. mysql-test/r/partition.result: Bug#46639: 1030 (HY000): Got error 124 from storage engine on INSERT ... SELECT ... updated result file mysql-test/t/partition.test: Bug#46639: 1030 (HY000): Got error 124 from storage engine on INSERT ... SELECT ... Added testcase sql/ha_partition.cc: Bug#46639: 1030 (HY000): Got error 124 from storage engine on INSERT ... SELECT ... reverted the patch for bug#38005, since that was a workaround around this problem, not needed after fixing it in myisam. storage/myisam/mi_search.c: Bug#46639: 1030 (HY000): Got error 124 from storage engine on INSERT ... SELECT ... Return HA_ERR_END_OF_FILE instead of HA_ERR_WRONG_INDEX when there are no rows.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Martin Hansson authored
-
Martin Hansson authored
-
Ramil Kalimullin authored
(temporary) TABLE, crash Problem: if one has an open "HANDLER t1", further "TRUNCATE t1" doesn't close the handler and leaves handler table hash in an inconsistent state, that may lead to a server crash. Fix: TRUNCATE should implicitly close all open handlers. Doc. request: the fact should be described in the manual accordingly. mysql-test/r/handler_myisam.result: Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP (temporary) TABLE, crash - test result. mysql-test/t/handler_myisam.test: Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP (temporary) TABLE, crash - test case. sql/sql_delete.cc: Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP (temporary) TABLE, crash - remove all truncated tables from the HANDLER's hash.
-
- 20 Aug, 2009 3 commits
-
-
Georgi Kodinov authored
-
Martin Hansson authored
mysql-test/r/auto_increment.result: Bug#46616: Test result. mysql-test/t/auto_increment.test: Bug#46616: Test case. sql/sql_update.cc: Bug#46616: Fix.
-
Martin Hansson authored
view manipulations The bespoke flag was not properly reset after last call to fill_record. Fixed by resetting in caller mysql_update. mysql-test/r/auto_increment.result: Bug#46616: Test result. mysql-test/t/auto_increment.test: Bug#46616: Test case. sql/sql_update.cc: Bug#46616: Fix.
-