An error occurred fetching the project authors.
- 18 Jan, 2010 1 commit
-
-
Georgi Kodinov authored
error in the query. Fixes a leak after materializing a GROUP BY subquery to a temp table when the subquery has a blob column in the SELECT list. Fixed by correctly destructing temporary buffers after doing the conversion.
-
- 22 Dec, 2009 2 commits
-
-
Georgi Kodinov authored
Several problems fixed : 1. Non constant expressions in UNION ... ORDER BY were not correctly cleaned up in st_select_lex_unit::cleanup() causing crashes in EXPLAIN EXTENDED because of fields quoted by these expressions pointing to the already freed temporary table used to calculate the UNION. Fixed by correctly cleaning up expressions of any depth. 2. Subqueries in the order by part of UNION ... ORDER BY ... caused a crash in EXPLAIN EXTENDED because of a transformation attempt made during EXPLAIN EXTENDED execution. Fixed by not doing the transformation when in EXPLAIN. 3. Fulltext functions caused crash when in the ORDER BY part of an un-parenthesized UNION that gets "promoted" to be valid for the whole union, e.g. SELECT * FROM t1 UNION SELECT * FROM t2 ORDER BY MATCHES (a) AGAINST ('abc' IN BOOLEAN MODE). This is a case that demonstrates a more general problem of parts of the query being moved to another level. When doing such transformation late in the optimization run when most of the flags about the contents of the query are already aggregated it's possible to "split" the flags so that they correctly reflect the new queries after the transformation. In specific the ST_SELECT_LEX::ftfunc_list is holding all the free text function for all the parts of the second SELECT in the UNION and we don't know what part of that is in the ORDER BY that we're to move to the UNION level and what part is about the other parts of the second SELECT. Fixed by throwing and error when such statements are about to be processed by adding a check for the presence of MATCH() inside the ORDER BY clause that's going to get promoted to UNION. To workaround this new limitation one must parenthesize the UNION SELECTs and provide a real global ORDER BY for the UNION outside of the parenthesis.
-
Ramil Kalimullin authored
on re-execution of prepared statement Problem: some (see eq_ref_table()) ORDER BY/GROUP BY optimization is called before each PS execution. However, we don't properly initialize its stucture every time before the call. Fix: properly initialize the sturture used. mysql-test/r/ps.result: Fix for bug#49570: Assertion failed: !(order->used & map) on re-execution of prepared statement - test result. mysql-test/t/ps.test: Fix for bug#49570: Assertion failed: !(order->used & map) on re-execution of prepared statement - test case. sql/sql_select.cc: Fix for bug#49570: Assertion failed: !(order->used & map) on re-execution of prepared statement - set order->used to 0 before each eq_ref_table() call, as the function relies on that.
-
- 17 Dec, 2009 1 commit
-
-
Martin Hansson authored
returns incorrect results with where An outer join of a const table (outer) and a normal table (inner) with GROUP BY on a field from the outer table would optimize away GROUP BY, and thus trigger the optimization to do away with a temporary table if grouping was performed on columns from the const table, hence executing the query with filesort without temporary table. But this should not be done if there is a non-indexed access to the inner table, since filesort does not handle joins. It expects either ref access, range ditto or table scan. The join condition will thus not be applied. Fixed by always forcing execution with temporary table in the case of ROLLUP with a query involving an outer join. This is a slightly broader class of queries than need fixing, but it is hard to ascertain the position of a ROLLUP field wrt outer join with current query representation. mysql-test/r/join_outer.result: Bug#47650: Test result mysql-test/t/join_outer.test: Bug#47650: Test case sql/sql_select.cc: Bug#47650: Fix
-
- 15 Dec, 2009 2 commits
-
-
Georgi Kodinov authored
int join_read_key(JOIN_TAB*) The eq_ref access method TABLE_REF (accessed through JOIN_TAB) to save state and to track if this is the first row it finds or not. This state was not reset on subquery re-execution causing an assert. Fixed by resetting the state before the subquery re-execution.
-
Georgi Kodinov authored
int join_read_key(JOIN_TAB*) The eq_ref access method TABLE_REF (accessed through JOIN_TAB) to save state and to track if this is the first row it finds or not. This state was not reset on subquery re-execution causing an assert. Fixed by resetting the state before the subquery re-execution.
-
- 09 Dec, 2009 1 commit
-
-
Olav Sandstaa authored
This fix has been proposed by Sergey Petrunya and has been contributed under SCA by sca@askmonty.org. The cause for this valgrind error is that in the function add_cond_and_fix() in sql_select.cc an Item_cond_and object is created. This is marked as fixed but does not have a correct table_map() attribute. Later, in make_join_select(), if engine_condition_pushdown is in use, this table map is used and results in the valgrind error. The fix is to add a call to update_used_tables() in add_cond_and_fix() so that the table map is updated correctly. This patch is tested by multiple existing tests (e.g. the tests innodb_mysql, innodb, fulltext, compress all produces this valgrind warning/error without this fix). sql/sql_select.cc: In add_cond_and_fix() add a call to update_used_tables() to ensure the table map is updated.
-
- 07 Dec, 2009 1 commit
-
-
Georgi Kodinov authored
Part 2 : There was a special optimization on the ref access method for ORDER BY ... DESC that was set without actually looking on the type of the selected index for ORDER BY. Fixed the SELECT ... ORDER BY .. DESC (it uses a different code path compared to the ASC that has been fixed with the previous fix).
-
- 04 Dec, 2009 1 commit
-
-
Ramil Kalimullin authored
field='const1' AND field='const2' in some cases Building multiple equality predicates containing a constant which is compared as a datetime (with a field) we should take this fact into account and compare the constant with another possible constatns as datetimes as well. E.g. for the SELECT ... WHERE a='2001-01-01' AND a='2001-01-01 00:00:00' we should compare '2001-01-01' with '2001-01-01 00:00:00' as datetimes but not as strings. mysql-test/r/select.result: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - test result. mysql-test/t/select.test: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - test case. sql/item_cmpfunc.cc: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - adding a constant to Item_equal compare it as a datetime value with stored one if there's a date[time] field in a equality predicate. sql/item_cmpfunc.h: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - adding a constant to Item_equal compare it as a datetime value with stored one if there's a date[time] field in a equality predicate. sql/sql_select.cc: Fix for bug#49199: Optimizer handles incorrectly: field='const1' AND field='const2' in some cases - adding a constant to Item_equal compare it as a datetime value with stored one if there's a date[time] field in a equality predicate.
-
- 25 Nov, 2009 6 commits
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3190 [merge] > revision-id: kostja@sun.com-20091103174552-bfpak6r7ngf5cbjb > parent: magnus.blaudd@sun.com-20091103170719-6b64sjnivsiyz6xy > parent: kostja@sun.com-20091103165854-7di545xruez8w207 > committer: Konstantin Osipov <kostja@sun.com> > branch nick: 5.1-41756 > timestamp: Tue 2009-11-03 20:45:52 +0300 > message: > A fix and a test case for > Bug#41756 "Strange error messages about locks from InnoDB". > > In JT_EQ_REF (join_read_key()) access method, > don't try to unlock rows in the handler, unless certain that > a) they were locked > b) they are not used. > > Unlocking of rows is done by the logic of the nested join loop, > and is unaware of the possible caching that the access method may > have. This could lead to double unlocking, when a row > was unlocked first after reading into the cache, and then > when taken from cache, as well as to unlocking of rows which > were actually used (but taken from cache). > > Delegate part of the unlocking logic to the access method, > and in JT_EQ_REF count how many times a record was actually > used in the join. Unlock it only if it's usage count is 0. > > Implemented review comments. > ------------------------------------------------------------ > Use --include-merges or -n0 to see merged revisions.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3148.8.5 > revision-id: davi.arnaut@sun.com-20091102112139-pztthzy6qj8jzomn > parent: svoj@sun.com-20091103091902-vwszwwpfi1f4zrpn > committer: Davi Arnaut <Davi.Arnaut@Sun.COM> > branch nick: 48370-5.1 > timestamp: Mon 2009-11-02 09:21:39 -0200 > message: > Bug#48370: Absolutely wrong calculations with GROUP BY and decimal fields when using IF > Bug#45261: Crash, stored procedure + decimal > > Revert fix for Bug#45261 due to unforeseen bugs.
-
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.3964.1 > revision-id: alexey.kopytov@sun.com-20091030155453-0vlfwki805h9os62 > parent: joerg@mysql.com-20091016122941-rf6z0keqvmlgjfto > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com> > branch nick: my50-bug48131 > timestamp: Fri 2009-10-30 18:54:53 +0300 > message: > Bug #48131: crash group by with rollup, distinct, filesort, > with temporary tables > > There were two problems the test case from this bug was > triggering: > > 1. JOIN::rollup_init() was supposed to wrap all constant Items > into another object for queries with the WITH ROLLUP modifier > to ensure they are never considered as constants and therefore > are written into temporary tables if the optimizer chooses to > employ them for DISTINCT/GROUP BY handling. > > However, JOIN::rollup_init() was called before > make_join_statistics(), so Items corresponding to fields in > const tables could not be handled as intended, which was > causing all kinds of problems later in the query execution. In > particular, create_tmp_table() assumed all constant items > except "hidden" ones to be removed earlier by remove_const() > which led to improperly initialized Field objects for the > temporary table being created. This is what was causing crashes > and valgrind errors in storage engines. > > 2. Even when the above problem had been fixed, the query from > the test case produced incorrect results due to some > DISTINCT/GROUP BY optimizations being performed by the > optimizer that are inapplicable in the WITH ROLLUP case. > > Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations > when the WITH ROLLUP modifier is present, and splitting the > const-wrapping part of JOIN::rollup_init() into a separate > method which is now invoked after make_join_statistics() when > the const tables are already known.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 1810.3961.6 > revision-id: joro@sun.com-20091030094044-quadg0bwjy7cwqzw > parent: joro@sun.com-20091029152429-ks55fhrp4lhknyij > committer: Georgi Kodinov <joro@sun.com> > branch nick: B48293-5.0-bugteam > timestamp: Fri 2009-10-30 11:40:44 +0200 > message: > Bug #48293: crash with procedure analyse, view with > 10 columns, > having clause... > > The fix for bug 46184 was not very complete. It was not covering > views using temporary tables and multiple tables in a FROM clause. > Fixed by reverting the fix for 46184 and making a more general > check that is checking at the right execution stage and for all > of the non-supported cases. > Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden. > Updated the analyse.test and subselect.test accordingly.
-
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.
-
- 20 Nov, 2009 2 commits
-
-
Kristofer Pettersson authored
Not all my_hash_insert() calls are checked for return value. This patch adds appropriate checks and failure responses where needed. mysys/hash.c: * Debug hook for testing failures in my_hash_insert()
-
Georgi Kodinov authored
Bug #48370 Absolutely wrong calculations with GROUP BY and decimal fields when using IF Added the test cases in the above two bugs for regression testing. Added additional tests that demonstrate a incomplete fix. Added a new factory method for Field_new_decimal to create a field from an (decimal returning) Item. In the new method made sure that all the precision and length variables are capped in a proper way. This is required because Item's can have larger precision than the decimal fields and thus need to be capped when creating a field based on an Item type. Fixed the wrong typecast to Item_decimal.
-
- 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(). mysql-test/r/select.result: Add test for BUG#48052 mysql-test/t/select.test: Add test for BUG#48052 sql/sql_select.cc: Properly initialize Item_cond_and by calling fix_fields (instead of quick_fix_field) when the Item that "ANDs" WHERE clause conditions with HAVING clause conditions is created.
-
- 12 Nov, 2009 1 commit
-
-
Alexey Kopytov authored
-
- 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.
-
- 10 Nov, 2009 1 commit
-
-
Georgi Kodinov authored
values We should re-set the access method functions when changing the access method when switching to another index to avoid sorting. Fixed by doing a little re-engineering : encapsulating all the function assignment into a special function and calling it when flipping the indexes.
-
- 06 Nov, 2009 1 commit
-
-
Alexey Kopytov authored
only const tables The problem was caused by two shortcuts in the optimizer that are inapplicable in the ROLLUP case. Normally in a case when only const tables are involved in a query, DISTINCT clause can be safely optimized away since there may be only one row produced by the join. Similarly, we don't need to create a temporary table to resolve DISTINCT/GROUP BY/ORDER BY. Both of these are inapplicable when the WITH ROLLUP modifier is present. Fixed by disabling the said optimizations for the WITH ROLLUP case. mysql-test/r/olap.result: Added a test case for bug #48475. mysql-test/t/olap.test: Added a test case for bug #48475. sql/sql_select.cc: Disabled const-only table optimizations for the WITH ROLLUP case.
-
- 03 Nov, 2009 1 commit
-
-
Konstantin Osipov authored
Bug#41756 "Strange error messages about locks from InnoDB". In JT_EQ_REF (join_read_key()) access method, don't try to unlock rows in the handler, unless certain that a) they were locked b) they are not used. Unlocking of rows is done by the logic of the nested join loop, and is unaware of the possible caching that the access method may have. This could lead to double unlocking, when a row was unlocked first after reading into the cache, and then when taken from cache, as well as to unlocking of rows which were actually used (but taken from cache). Delegate part of the unlocking logic to the access method, and in JT_EQ_REF count how many times a record was actually used in the join. Unlock it only if it's usage count is 0. Implemented review comments. mysql-test/r/bug41756.result: Add result file (Bug#41756) mysql-test/t/bug41756-master.opt: Use --innodb-locks-unsafe-for-binlog, as in 5.0 just using read_committed isolation is not sufficient to reproduce the bug. mysql-test/t/bug41756.test: Add a test file (Bug#41756) sql/item_subselect.cc: Complete struct READ_RECORD initialization with a new member to unlock records. sql/records.cc: Extend READ_RECORD API with a method to unlock read records. sql/sql_select.cc: In JT_EQ_REF (join_read_key()) access method, don't try to unlock rows in the handler, unless certain that a) they were locked b) they are not used. sql/sql_select.h: Add members to TABLE_REF to count TABLE_REF buffer usage count. sql/structs.h: Update declarations.
-
- 02 Nov, 2009 1 commit
-
-
Davi Arnaut authored
Bug#45261: Crash, stored procedure + decimal Revert fix for Bug#45261 due to unforeseen bugs.
-
- 30 Oct, 2009 3 commits
-
-
Alexey Kopytov authored
with temporary tables There were two problems the test case from this bug was triggering: 1. JOIN::rollup_init() was supposed to wrap all constant Items into another object for queries with the WITH ROLLUP modifier to ensure they are never considered as constants and therefore are written into temporary tables if the optimizer chooses to employ them for DISTINCT/GROUP BY handling. However, JOIN::rollup_init() was called before make_join_statistics(), so Items corresponding to fields in const tables could not be handled as intended, which was causing all kinds of problems later in the query execution. In particular, create_tmp_table() assumed all constant items except "hidden" ones to be removed earlier by remove_const() which led to improperly initialized Field objects for the temporary table being created. This is what was causing crashes and valgrind errors in storage engines. 2. Even when the above problem had been fixed, the query from the test case produced incorrect results due to some DISTINCT/GROUP BY optimizations being performed by the optimizer that are inapplicable in the WITH ROLLUP case. Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations when the WITH ROLLUP modifier is present, and splitting the const-wrapping part of JOIN::rollup_init() into a separate method which is now invoked after make_join_statistics() when the const tables are already known. mysql-test/r/olap.result: Added a test case for bug #48131. mysql-test/t/olap.test: Added a test case for bug #48131. sql/sql_select.cc: 1. Disabled inapplicable DISTINCT/GROUP BY optimizations when the WITH ROLLUP modifier is present. 2. Split the const-wrapping part of JOIN::rollup_init() into a separate method. sql/sql_select.h: Added rollup_process_const_fields() declaration.
-
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.
-
Georgi Kodinov authored
having clause... The fix for bug 46184 was not very complete. It was not covering views using temporary tables and multiple tables in a FROM clause. Fixed by reverting the fix for 46184 and making a more general check that is checking at the right execution stage and for all of the non-supported cases. Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden. Updated the analyse.test and subselect.test accordingly.
-
- 29 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
Queries with nested outer joins may lead to crashes or bad results because an internal data structure is not handled correctly. The optimizer uses bitmaps of nested JOINs to determine if certain table can be placed at a certain place in the JOIN order. It does maintain a bitmap describing in which JOINs last placed table is nested. When it puts a table it makes sure the bit of every JOIN that contains the table in question is set (because JOINs can be nested). It does that by recursively setting the bit for the next enclosing JOIN when this is the first table in the JOIN and recursively resetting the bit if it's the last table in the JOIN. When it removes a table from the join order it should do the opposite : recursively unset the bit if it's the only remaining table in this join and and recursively set the bit if it's removing the last table of a JOIN. There was an error in how the bits was set for the upper levels : when removing a table it was setting the bit for all the enclosing nested JOINs even if there were more tables left in the current JOIN (which practically means that the upper nested JOINs were not affected). Fixed by stopping the recursion at the relevant level. mysql-test/r/join.result: Bug #42116: test case mysql-test/t/join.test: Bug #42116: test case sql/sql_select.cc: Bug #41116: don't go up and set the bits if more tables in at the current JOIN level
-
- 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. mysql-test/r/select.result: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - test result. mysql-test/t/select.test: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - test case. sql/sql_select.cc: Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, line 138 when forcing a spatial index - disable spatial indexes for queries which use non-spatial conditions (e.g. NATURAL JOINs).
-
- 14 Oct, 2009 2 commits
-
-
Jorgen Loland authored
Temporary tables may set join->group to 0 even though there is grouping. Also need to test if sum_func_count>0 when JOIN::exec() decides whether to present results in a grouped manner. sql/sql_select.cc: Temporary tables may set join->group to 0 even though there is grouping. Also need to test if sum_func_count>0 when JOIN::exec() decides whether to present results in a grouped manner.
-
Jorgen Loland authored
columns without where/group Simple SELECT with implicit grouping used to return many rows if the query was ordered by the aggregated column in the SELECT list. This was incorrect because queries with implicit grouping should only return a single record. The problem was that when JOIN:exec() decided if execution needed to handle grouping, it was assumed that sum_func_count==0 meant that there were no aggregate functions in the query. This assumption was not correct in JOIN::exec() because the aggregate functions might have been optimized away during JOIN::optimize(). The reason why queries without ordering behaved correctly was that sum_func_count is only recalculated if the optimizer chooses to use temporary tables (which it does in the ordered case). Hence, non-ordered queries were correctly treated as grouped. The fix for this bug was to remove the assumption that sum_func_count==0 means that there is no need for grouping. This was done by introducing variable "bool implicit_grouping" in the JOIN object. mysql-test/r/func_group.result: Add test for BUG#47280 mysql-test/t/func_group.test: Add test for BUG#47280 sql/opt_sum.cc: Improve comment for opt_sum_query() sql/sql_class.h: Add comment for variables in TMP_TABLE_PARAM sql/sql_select.cc: Introduce and use variable implicit_grouping instead of (!group_list && sum_func_count) in places that need to test if grouping is required. Also added comments for: optimization of aggregate fields for implicitly grouped queries (JOIN::optimize) and choice of end_select method (JOIN::execute) sql/sql_select.h: Add variable implicit_grouping, which will be TRUE for queries that contain aggregate functions but no GROUP BY clause. Also added comment to sort_and_group variable.
-
- 07 Oct, 2009 1 commit
-
-
Georgi Kodinov authored
buffering is used FORCE INDEX FOR ORDER BY now prevents the optimizer from using join buffering. As a result the optimizer can use indexed access on the first table and doesn't need to sort the complete resultset at the end of the statement.
-
- 30 Sep, 2009 1 commit
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2791.2.3 > revision-id: joro@sun.com-20090827114042-h55n7qp9990bl6ge > parent: anurag.shekhar@sun.com-20090831073231-e55y1hsck6n08ux8 > committer: Georgi Kodinov <joro@sun.com> > branch nick: B46749-5.0-bugteam > timestamp: Thu 2009-08-27 14:40:42 +0300 > message: > Bug #46749: Segfault in add_key_fields() with outer subquery level > field references > > This error requires a combination of factors : > 1. An "impossible where" in the outermost SELECT > 2. An aggregate in the outermost SELECT > 3. A correlated subquery with a WHERE clause that includes an outer > field reference as a top level WHERE sargable predicate > > When JOIN::optimize detects an "impossible WHERE" it will bail out > without doing the rest of the work and initializations. It will not > call make_join_statistics() as well. And make_join_statistics fills > in various structures for each table referenced. > When processing the result of the "impossible WHERE" the query must > send a single row of data if there are aggregate functions in it. > In this case the server marks all the aggregates as having received > no rows and calls the relevant Item::val_xxx() method on the SELECT > list. However if this SELECT list happens to contain a correlated > subquery this subquery is evaluated in a normal evaluation mode. > And if this correlated subquery has a reference to a field from the > outermost "impossible where" SELECT the add_key_fields will mistakenly > consider the outer field reference as a "local" field reference when > looking for sargable predicates. > But since the SELECT where the outer field reference refers to is not > completely initialized due to the "impossible WHERE" in this level > we'll get a NULL pointer reference. > Fixed by making a better condition for discovering if a field is "local" > to the SELECT level being processed. > It's not enough to look for OUTER_REF_TABLE_BIT in this case since > for outer references to constant tables the Item_field::used_tables() > will return 0 regardless of whether the field reference is from the > local SELECT or not.
-
- 23 Sep, 2009 1 commit
-
-
Sergey Glukhov authored
the fix is reverted from 5.1, mysql-pe as unnecessary(no valgrind warnings there). sql/sql_select.cc: the fix is reverted from 5.1, mysql-pe as unnecessary(no valgrind warnings there).
-
- 22 Sep, 2009 2 commits
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3092.1.2 [merge] > revision-id: joro@sun.com-20090831134035-wndnw04gy8kzogpm > parent: anurag.shekhar@sun.com-20090831075609-tkpqu41hxtupdeip > parent: joro@sun.com-20090827114042-h55n7qp9990bl6ge > committer: Georgi Kodinov <joro@sun.com> > branch nick: B46749-5.1-bugteam > timestamp: Mon 2009-08-31 16:40:35 +0300 > message: > automerge > ------------------------------------------------------------ > Use --include-merges or -n0 to see merged revisions.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3059 [merge] > revision-id: martin.hansson@sun.com-20090810140851-aw5peehzdxi4gjja > parent: iggy@mysql.com-20090806145453-ion37sfdsldwwjrj > parent: martin.hansson@sun.com-20090807115140-7fn6wjx0mrui7zl5 > committer: Martin Hansson <martin.hansson@sun.com> > branch nick: 5.1bt > timestamp: Mon 2009-08-10 16:08:51 +0200 > message: > Merge > ------------------------------------------------------------ > Use --include-merges or -n0 to see merged revisions.
-
- 18 Sep, 2009 1 commit
-
-
Georgi Kodinov authored
query The fix for bug 46749 removed the check for OUTER_REF_TABLE_BIT and substituted it for a check on the presence of Item_ident::depended_from. Removing it altogether was wrong : OUTER_REF_TABLE_BIT should still be checked in addition to depended_from (because it's not set in all cases and doesn't contradict to the check of depended_from). Fixed by returning the old condition back as a compliment to the new one.
-
- 17 Sep, 2009 1 commit
-
-
Staale Smedseng authored
with gcc 4.3.2 This is the fifth patch cleaning up more GCC warnings about variables used before initialized using the new macro UNINIT_VAR().
-
- 05 Sep, 2009 1 commit
-
-
Alexey Kopytov authored
The external 'for' loop in remove_dup_with_compare() handled HA_ERR_RECORD_DELETED by just starting over without advancing to the next record which caused an infinite loop. This condition could be triggered on certain data by a SELECT query containing DISTINCT, GROUP BY and HAVING clauses. Fixed remove_dup_with_compare() so that we always advance to the next record when receiving HA_ERR_RECORD_DELETED from rnd_next(). mysql-test/r/distinct.result: Added a test case for bug #46159. mysql-test/t/distinct.test: Added a test case for bug #46159. sql/sql_select.cc: Fixed remove_dup_with_compare() so that we always advance to the next record when receiving HA_ERR_RECORD_DELETED from rnd_next().
-
- 04 Sep, 2009 1 commit
-
-
Sergey Glukhov authored
Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up. The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy. mysql-test/r/explain.result: test result mysql-test/t/explain.test: test case sql/sql_select.cc: Memory allocated in TMP_TABLE_PARAM::copy_field is not cleaned up. The fix is to clean up TMP_TABLE_PARAM::copy_field array in JOIN::destroy.
-