An error occurred fetching the project authors.
- 15 Dec, 2009 2 commits
-
-
Ramil Kalimullin authored
NULLable BIGINT and INT columns in comparison Problem: a consequence of the fix for 43668. Some Arg_comparator inner initialization missed, that may lead to unpredictable (wrong) comparison results. Fix: always properly initialize Arg_comparator before its usage.
-
Georgi Kodinov authored
Merge the fix from 5.1-bugteam to 5.1-main
-
- 25 Nov, 2009 2 commits
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 1810.3961.7 > committer: Georgi Kodinov <joro@sun.com> > branch nick: B48291-5.0-bugteam > timestamp: Fri 2009-10-30 15:15:43 +0200 > message: > Bug #48291 : crash with row() operator,select into @var, and > subquery returning multiple rows > > Error handling was missing when handling subqueires in WHERE > and when assigning a SELECT result to a @variable. > This caused crash(es). > > Fixed by adding error handling code to both the WHERE > condition evaluation and to assignment to an @variable. > ------------------------------------------------------------
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 1810.3959.4 > revision-id: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c > parent: azundris@mysql.com-20091021033856-ydodp4q42o58e7ka > committer: Ramil Kalimullin <ramil@mysql.com> > branch nick: b47019-5.0-bugteam > timestamp: Wed 2009-10-21 14:04:08 +0500 > message: > Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, > line 138 when forcing a spatial index > > Problem: "Spatial indexes can be involved in the search > for queries that use a function such as MBRContains() > or MBRWithin() in the WHERE clause". > Using spatial indexes for JOINs with =, <=> etc. > predicates is incorrect. > > Fix: disable spatial indexes for such queries.
-
- 13 Nov, 2009 1 commit
-
-
Jorgen Loland authored
init_read_record() - (records.cc:274) Item_cond::used_tables_cache was accessed in records.cc#init_read_record() without being initialized. It had not been initialized because it was wrongly assumed that the Item's variables would not be accessed, and hence quick_fix_field() was used instead of fix_fields() to save a few CPU cycles at creation time. The fix is to properly initilize the Item by replacing quick_fix_field() with fix_fields().
-
- 09 Nov, 2009 1 commit
-
-
Georgi Kodinov authored
memory The server was doing a bad class typecast causing setting of wrong value for the maximum number of items in an internal structure used in equality propagation. Fixed by not doing the wrong typecast and asserting the type of the Item where it should be done.
-
- 30 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
subquery returning multiple rows Error handling was missing when handling subqueires in WHERE and when assigning a SELECT result to a @variable. This caused crash(es). Fixed by adding error handling code to both the WHERE condition evaluation and to assignment to an @variable.
-
- 21 Oct, 2009 1 commit
-
-
Ramil Kalimullin authored
line 138 when forcing a spatial index Problem: "Spatial indexes can be involved in the search for queries that use a function such as MBRContains() or MBRWithin() in the WHERE clause". Using spatial indexes for JOINs with =, <=> etc. predicates is incorrect. Fix: disable spatial indexes for such queries.
-
- 26 Jun, 2009 1 commit
-
-
Evgeny Potemkin authored
The TABLE::reginfo.impossible_range is used by the optimizer to indicate that the condition applied to the table is impossible. It wasn't initialized at table opening and this might lead to an empty result on complex queries: a query might set the impossible_range flag on a table and when the query finishes, all tables are returned back to the table cache. The next query that uses the table with the impossible_range flag set and an index over the table will see the flag and thus return an empty result. The open_table function now initializes the TABLE::reginfo.impossible_range variable.
-
- 28 Apr, 2009 1 commit
-
-
Gleb Shchepa authored
Bug #40925: Equality propagation takes non indexed attribute Query execution plans and execution time of queries like select a, b, c from t1 where a > '2008-11-21' and b = a limit 10 depended on the order of equality operator parameters: "b = a" and "a = b" are not same. An equality propagation algorithm has been fixed: the substitute_for_best_equal_field function should not substitute a field for an equal field if both fields belong to the same table.
-
- 16 Mar, 2009 1 commit
-
-
Ramil Kalimullin authored
select where .. (col=col and col=col) or ... (false expression) Problem: optimizer didn't take into account a singular case when we eliminated all the predicates at the AND level of WHERE. That may lead to wrong results. Fix: replace (a=a AND a=a...) with TRUE if we eliminated all the predicates.
-
- 24 Dec, 2008 1 commit
-
-
Sergey Glukhov authored
Table could be marked dependent because it is either 1) an inner table of an outer join, or 2) it is a part of STRAIGHT_JOIN. In case of STRAIGHT_JOIN table->maybe_null should not be assigned. The fix is to set st_table::maybe_null to 'true' only for those tables which are used in outer join.
-
- 09 Dec, 2008 1 commit
-
-
Georgi Kodinov authored
Field_varstring::store The code that temporary saved the bitmaps of the read set and the write set so that it can set it to all columns for debug purposes was not expecting that the table->read_set and table->write_set can be the same. And was always saving both in sequence. As a result the original value was never restored. Fixed by saving & restoring the original value only once if the two sets are the same (in a special set of functions).
-
- 17 Feb, 2008 1 commit
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
Problem is not about intervals and doesn't actually cause 'full table scan'. We have an optimization for DISTINCT when we have 'DISTINCT field_from_first_join_table' we don't need to read all the rows from the JOIN-ed table if we found one conforming row. It stopped working in 5.0 as we return NESTED_LOOP_OK if we came upon that case in the evaluate_join_record() and that doesn't break the recordreading loop in sub_select(). Fixed by returning NESTED_LOOP_NO_MORE_ROWS in this case.
-
- 13 Feb, 2008 1 commit
-
-
gshchepa/uchum@host.loc authored
type conversion. Instead of copying of whole character string from a temporary buffer, the server copied a short-living pointer to that string into a long-living structure. That has been fixed.
-
- 17 Nov, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
Comparison of a BIGINT NOT NULL column with a constant arithmetic expression that evaluates to NULL caused error 1048: "Column '...' cannot be null". Made convert_constant_item() check if the constant expression is NULL before attempting to store it in a field. Attempts to store NULL in a NOT NULL field caused query errors.
-
- 14 Nov, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
-
- 10 Nov, 2007 1 commit
-
-
BETWEEN was more lenient with regard to what it accepted as a DATE/DATETIME in comparisons than greater-than and less-than were. ChangeSet makes < > comparisons similarly robust with regard to trailing garbage (" GMT-1") and "missing" leading zeros. Now all three comparators behave similarly in that they throw a warning for "junk" at the end of the data, but then proceed anyway if possible. Before < > fell back on a string- (rather than date-) comparison when a warning-condition was raised in the string-to-date conversion. Now the fallback only happens on actual errors, while warning- conditions still result in a warning being to delivered to the client.
-
- 07 Nov, 2007 2 commits
-
-
kaa@polly.(none) authored
variable in where clause. Problem: the new_item() method of Item_uint used an incorrect constructor. "new Item_uint(name, max_length)" calls Item_uint::Item_uint(const char *str_arg, uint length) which assumes the first argument to be the string representation of the value, not the item's name. This could result in either a server crash or incorrect results depending on usage scenarios. Fixed by using the correct constructor in new_item(): Item_uint::Item_uint(const char *str_arg, longlong i, uint length).
-
kaa@polly.(none) authored
tables or more The problem was that the optimizer used the join buffer in cases when the result set is ordered by filesort. This resulted in the ORDER BY clause being ignored, and the records being returned in the order determined by the order of matching records in the last table in join. Fixed by relaxing the condition in make_join_readinfo() to take filesort-ordered result sets into account, not only index-ordered ones.
-
- 25 Oct, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
all space column names. The parser has been modified to check VIEW column names with the check_column_name function and to report an error on empty and all space column names (same as for TABLE column names).
-
- 23 Oct, 2007 1 commit
-
-
anozdrin/alik@station. authored
Inserting Data. The problem was that under some circumstances Field class was not properly initialized before calling create_length_to_internal_length() function, which led to assert failure. The fix is to do the proper initialization. The user-visible problem was that under some circumstances CREATE TABLE ... SELECT statement crashed the server or led to wrong error message (wrong results).
-
- 19 Sep, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
The parser uses ulonglong to store the LIMIT number. This number then is stored into a variable of type ha_rows. ha_rows is either 4 or 8 byte depending on the BIG_TABLES define from config.h So an overflow may occur (and LIMIT becomes zero) while storing an ulonglong value in ha_rows. Fixed by : 1. Using the maximum possible value for ha_rows on overflow 2. Defining BIG_TABLES for the windows builds (to match the others)
-
- 15 Sep, 2007 1 commit
-
-
gshchepa@devsrv-b.mysql.com authored
Post-fix for bug#27695.
-
- 13 Sep, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
Declaring an all space column name in the SELECT FROM DUAL or in a view leads to misleading warning message: "Leading spaces are removed from name ' '". The Item::set_name method has been modified to raise warnings like "Name ' ' has become ''" in case of the truncation of an all space identifier to an empty string identifier instead of the "Leading spaces are removed from name ' '" warning message.
-
- 23 Aug, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
Recommit to 5.1.22. The bug caused memory corruption for some queries with top OR level in the WHERE condition if they contained equality predicates and other sargable predicates in disjunctive parts of the condition. The corruption happened because the upper bound of the memory allocated for KEY_FIELD and SARGABLE_PARAM internal structures containing info about potential lookup keys was calculated incorrectly in some cases. In particular it was calculated incorrectly when the WHERE condition was an OR formula with disjuncts being AND formulas including equalities and other sargable predicates.
-
- 15 Aug, 2007 1 commit
-
-
igor@olga.mysql.com authored
The bug caused memory corruption for some queries with top OR level in the WHERE condition if they contained equality predicates and other sargable predicates in disjunctive parts of the condition. The corruption happened because the upper bound of the memory allocated for KEY_FIELD and SARGABLE_PARAM internal structures containing info about potential lookup keys was calculated incorrectly in some cases. In particular it was calculated incorrectly when the WHERE condition was an OR formula with disjuncts being AND formulas including equalities and other sargable predicates.
-
- 02 Aug, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
The SELECT query with more than 31 nested dependent SELECT queries returned wrong result. New error message has been added: ER_TOO_HIGH_LEVEL_OF_NESTING_FOR_SELECT. It will be reported as: "Too high level of nesting for select".
-
- 10 Apr, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
Added a test case. The problem was fixed by the fix for bug #17379. The problem was that because of some conditions the optimizer always preferred range or full index scan access methods to lookup access methods even when the latter were much cheaper.
-
- 26 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
enabled the optional FOR JOIN to all the three clauses : USE, FORCE and IGNORE
-
- 12 Mar, 2007 1 commit
-
-
igor@olga.mysql.com authored
after single-row table substitution could lead to a wrong result set. The bug happened because the function Item_field::replace_equal_field erroniously assumed that any field included in a multiple equality with a constant has been already substituted for this constant. This not true for fields becoming constant after row substitutions for constant tables.
-
- 09 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
be specified 5.0 part of the fix. Implements IGNORE INDEX FOR JOIN as a synonym of IGNORE INDEX for backward compatibility with the 5.1 fix.
-
- 15 Feb, 2007 1 commit
-
-
igor@olga.mysql.com authored
were evaluated. According to the new rules for string comparison partial indexes on text columns can be used in the same cases when partial indexes on varchar columns can be used.
-
- 13 Feb, 2007 1 commit
-
-
igor@olga.mysql.com authored
-
- 06 Feb, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
Ignoring error codes from type conversion allows default (wrong) values to go unnoticed in the formation of index search conditions. Fixed by correctly checking for conversion errors.
-
- 01 Feb, 2007 1 commit
-
-
igor@olga.mysql.com authored
The bug could cause choosing a sub-optimal execution plan for a single-table query if a unique index with many null keys were defined for the table. It happened because the code of the check_quick_keys function made an assumption that any key may occur in an unique index only once. Yet this is not true for keys with nulls that may have multiple occurrences in the index.
-
- 22 Jan, 2007 1 commit
-
-
We use INT_RESULT type if all arguments are of type INT for 'if', 'case', 'coalesce' functions regardless of arguments' unsigned flag, so sometimes we can exceed the INT bounds.
-
- 19 Jan, 2007 1 commit
-
-
evgen@moonbone.local authored
After fix for bug#21798 JOIN stores the pointer to the buffer for sorting fields. It is used while sorting for grouping and for ordering. If ORDER BY clause has more elements then the GROUP BY clause then a memory overrun occurs. Now the length of the ORDER BY list is always passed to the make_unireg_sortorder() function and it allocates buffer big enough to be used for bigger list.
-
- 03 Jan, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
With MySQL 3.23 and 4.0, the syntax 'LIMIT N, -1' is accepted, and returns all the rows located after row N. This behavior, however, is not the intended result, and defeats the purpose of LIMIT, which is to constrain the size of a result set. With MySQL 4.1 and later, this construct is correctly detected as a syntax error. This fix does not change the production code, and only adds a new test case to improve test coverage in this area, to enforce in the test suite the intended behavior.
-
- 06 Dec, 2006 1 commit
-
-
Problem: storing >=8 byte hexadecimal values we don't check data. Fix: check if the data fits the {u}longlong range.
-