- 24 Mar, 2010 2 commits
-
-
Sergey Glukhov authored
-
Sergey Glukhov authored
The crash happens because greedy_serach can not determine best plan due to wrong inner table dependences. These dependences affects join table sorting which performs before greedy_search starting. In our case table which has real 'no dependences' should be put on top of the list but it does not happen as inner tables have no dependences as well. The fix is to exclude RAND_TABLE_BIT mask from condition which checks if table dependences should be updated.
-
- 23 Mar, 2010 1 commit
-
-
Georgi Kodinov authored
col equal to itself! There's no need to copy the value of a field into itself. While generally harmless (except for some performance penalties) it may be dangerous when the copy code doesn't expect this. Fixed by checking if the source field is the same as the destination field before copying the data. Note that we must preserve the order of assignment of the null flags (hence the null_value assignment addition).
-
- 22 Mar, 2010 7 commits
-
-
Alexander Barkov authored
-
Alexander Barkov authored
Problem: caseup_multiply and casedn_multiply members were not initialized for a dynamic collation, so UPPER() and LOWER() functions returned empty strings. Fix: initializing the members properly. Adding tests: mysql-test/r/ctype_ldml.result mysql-test/t/ctype_ldml.test Applying the fix: mysys/charset.c
-
Mats Kindahl authored
-
Mats Kindahl authored
for InnoDB Patch to fix result files for the binlog suite under row- based replication.
-
John H. Embretsen authored
-
Gleb Shchepa authored
Bug #49910: Behavioural change in SELECT/WHERE on YEAR(4) data type (Original patch by Sinisa Milivojevic) The YEAR(4) value of 2000 was equal to the "bad" YEAR(4) value of 0000. The get_year_value() function has been modified to not adjust bad YEAR(4) value to 2000.
-
Andrei Elkin authored
comments to rpl_show_slave_running test are added to ease merging
-
- 21 Mar, 2010 1 commit
-
-
Andrei Elkin authored
-
- 19 Mar, 2010 5 commits
-
-
Sergey Glukhov authored
The problem is that when we make conditon for grouped result const part of condition is cut off. It happens because some parts of 'having' condition which refer to outer join become const after make_join_statistics. These parts may be lost during further having condition transformation in JOIN::exec. The fix is adding 'having' condition check for const tables after make_join_statistics is performed.
-
Andrei Elkin authored
DBUG_SYNC_POINT has at least one strong limitation that it's not defined on all platforms. It has issues cooperating with @@debug. All in all its functionality is superseded by DEBUG_SYNC facility and there is no reason to maintain the old less flexible one. Fixed with adding debug_sync_set_action() function as a facility to set up a sync-action in the server sources code and re-writing existing simulations (found 3) to use it. Couple of tests have been reworked as well. The patch offers a pattern for setting sync-points in replication threads where the standard DEBUG_SYNC does not suffice to reach goals.
-
Martin Hansson authored
This has been back-ported from 6.0 as the problems proved to afflict 5.1 as well. The fix exposed two new bugs. They were reported as follows. Bug no 52174: Sometimes wrong plan when reading a MAX value from non-NULL index Bug no 52173: Reading NULL value from non-NULL index gives wrong result in embedded server Both bugs taken together affect a much smaller class of queries than #47762, so the fix stays for now.
-
Sergey Glukhov authored
Optimizer erroneously translated LEFT JOIN into INNER JOIN. It leads to cutting rows with NULL right side. It happens because Item_row uses not_null_tables() method form the base(Item) class and does not calculate 'null tables' properly. The fix is adding calculation of 'not null tables' to Item_row.
-
Sergey Glukhov authored
The crash happens because of discrepancy between values of conts_tables and join->const_table_map(make_join_statisctics). Calculation of conts_tables used condition with HA_STATS_RECORDS_IS_EXACT flag check. Calculation of join->const_table_map does not use this flag check. In case of MERGE table without union with index the table does not become const table and thus join_read_const_table() is not called for the table. join->const_table_map supposes this table is const and later in make_join_select this table is used for making&calculation const condition. As table record buffer is not populated it leads to crash. The fix is adding a check if an engine supports HA_STATS_RECORDS_IS_EXACT flag before updating join->const_table_map.
-
- 18 Mar, 2010 2 commits
-
-
John H. Embretsen authored
reverse DNS lookup of "localhost" returns "broadcasthost" on Snow Leopard, and NULL on most others. Simply ignore the output, as this is not an essential part of UDF testing.
-
Omer BarNir authored
for general use.
-
- 17 Mar, 2010 3 commits
-
-
Mats Kindahl authored
-
Mats Kindahl authored
for InnoDB The class Field_bit_as_char stores the metadata for the field incorrecly because bytes_in_rec and bit_len are set to (field_length + 7 ) / 8 and 0 respectively, while Field_bit has the correct values field_length / 8 and field_length % 8. Solved the problem by re-computing the values for the metadata based on the field_length instead of using the bytes_in_rec and bit_len variables. To handle compatibility with old server, a table map flag was added to indicate that the bit computation is exact. If the flag is clear, the slave computes the number of bytes required to store the bit field and compares that instead, effectively allowing replication *without conversion* from any field length that require the same number of bytes to store.
-
Georgi Kodinov authored
definition at engine If a single ALTER TABLE contains both DROP INDEX and ADD INDEX using the same index name (a.k.a. index modification) we need to disable in-place alter table because we can't ask the storage engine to have two copies of the index with the same name even temporarily (if we first do the ADD INDEX and then DROP INDEX) and we can't modify indexes that are needed by e.g. foreign keys if we first do DROP INDEX and then ADD INDEX. Fixed the problem by disabling in-place ALTER TABLE for these cases.
-
- 14 Mar, 2010 2 commits
-
-
Staale Smedseng authored
SunStudio SunStudio compilers of late warn about methods that might hide methods in base classes due to the use of overloading combined with overriding. SunStudio also warns about variables defined in local socpe or method arguments that have the same name as a member attribute of the class. This patch renames methods that might hide base class methods, to make it easier both for humans and compilers to see what is actually called. It also renames variables in local scope.
-
Davi Arnaut authored
-
- 13 Mar, 2010 1 commit
-
-
Davi Arnaut authored
-
- 10 Mar, 2010 4 commits
-
-
Sergey Vojtovich authored
BUG#51342 - more xid crashing Restore autocommit variable by supplying explicit value.
-
Sergey Vojtovich authored
-
Sergey Vojtovich authored
SET autocommit=1 while XA transaction is active may cause various side effects, including memory corruption and server crash. The problem is that SET autocommit=1 and further queries attempt to commit local transaction, whereas XA transaction is still active. As local and XA transactions are mutually exclusive, this patch forbids enabling autocommit mode while XA transaction is active.
-
Georgi Kodinov authored
-
- 09 Mar, 2010 1 commit
-
-
Davi Arnaut authored
The problem was that killing a query during the optimization phase of a subselect would lead to crashes. The root of the problem is that the subselect execution engine ignores failures (eg: killed) during the optimization phase (JOIN::optimize), leading to a crash once the subquery is executed due to partially initialized structures (in this case a join tab). The optimal solution would be to cleanup certain optimizer structures if the optimization phase fails, but currently there is no infrastructure to properly to track and cleanup the structures. To workaround the whole problem one somewhat good solution is to avoid executing a subselect if the query has been killed. Cutting short any problems caused by failures during the optimization phase.
-
- 16 Mar, 2010 8 commits
-
-
Sergey Vojtovich authored
-
Martin Hansson authored
-
Martin Hansson authored
NULL column for NULL The optimization to read MIN() and MAX() values from an index did not properly handle comparisons with NULL values. Fixed by giving up the particular optimization step if there are non-NULL safe comparisons with NULL values, as the result is NULL anyway. Also, Oracle copyright notice was added to all files.
-
Mattias Jonsson authored
-
Sergey Vojtovich authored
-
Sergey Vojtovich authored
via I_S.PLUGINS, not via SHOW PLUGINS.
-
Luis Soares authored
-
Martin Hansson authored
Base Tables The type inferrence of a view column caused the result to be interpreted as the wrong type: DATE colums were interpreted as TIME and TIME as DATETIME. This happened because view columns are represented by Item_ref objects as opposed to Item_field's. Item_ref had no method for retrieving a TIME value and thus was forced to depend on the default implementation for any expression, which caused the expression to be evaluated as a string and then parsed into a TIME/DATETIME value. Fixed by letting Item_ref classes forward the request for a TIME value to the referred Item - which is a field in this case - this reads the TIME value directly without conversion.
-
- 15 Mar, 2010 1 commit
-
-
Davi Arnaut authored
Fix up function return value, it must return a double.
-
- 12 Mar, 2010 2 commits
-
-
Mattias Jonsson authored
-
Sergey Vojtovich authored
index cardinalities=1 Parallel repair didn't poroperly update index cardinality in certain cases. When myisam_sort_buffer_size is not enough to store all keys, index cardinality was updated before index was actually written, when no index statistic is available.
-