- 25 Nov, 2009 14 commits
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3181 > revision-id: alexey.kopytov@sun.com-20091016201951-fsht0wm8xn8vkzsx > parent: joerg@mysql.com-20091016164025-kb4sbrggq5o7zufc > committer: Alexey Kopytov <Alexey.Kopytov@Sun.com> > branch nick: mysql-5.1-bugteam > timestamp: Sat 2009-10-17 00:19:51 +0400 > message: > Bug #47123: Endless 100% CPU loop with STRAIGHT_JOIN > > The problem was in incorrect handling of predicates involving > NULL as a constant value by the range optimizer. > > For example, when creating a SEL_ARG node from a condition of > the form "field < const" (which would normally result in the > "NULL < field < const" SEL_ARG), the special case when "const" > is NULL was not taken into account, so "NULL < field < NULL" > was produced for the "field < NULL" condition. > > As a result, SEL_ARG structures of this form could not be > further optimized which in turn could lead to incorrectly > constructed SEL_ARG trees. In particular, code assuming SEL_ARG > structures to always form a sequence of ordered disjoint > intervals could enter an infinite loop under some > circumstances. > > Fixed by changing get_mm_leaf() so that for any sargable > predicate except "<=>" involving NULL as a constant, "empty" > SEL_ARG is returned, since such a predicate is always false.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3148.9.6 > revision-id: martin.hansson@sun.com-20091102122407-krzh4h0i052lbwr5 > parent: davi.arnaut@sun.com-20091102112236-k3myix2xy8miyv4s > committer: Martin Hansson <martin.hansson@sun.com> > branch nick: 5.1bt > timestamp: Mon 2009-11-02 13:24:07 +0100 > message: > Bug#47925: regression of range optimizer and date comparison in 5.1.39! > > When a query was using a DATE or DATETIME value formatted > using any other separator characters beside hyphen '-', a > query with a greater-or-equal '>=' condition matching only > the greatest value in an indexed column, the result was > empty if index range scan was employed. > > The range optimizer got a new feature between 5.1.38 and > 5.1.39 that changes a greater-or-equal condition to a > greater-than if the value matching that in the query was not > present in the table. But the value comparison function > compared the dates as strings instead of dates. > > The bug was fixed by splitting the function > get_date_from_str in two: One part that parses and does > error checking. This function is now visible outside the > module. The old get_date_from_str now calls the new > function.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3148.9.3 > revision-id: azundris@mysql.com-20091029230154-jp2xqvzw2nhj9q41 > parent: azundris@mysql.com-20091027095316-54lwjr9vqkscq1ik > committer: Tatiana A. Nurnberg <azundris@mysql.com> > branch nick: 51-48295 > timestamp: Thu 2009-10-29 16:01:54 -0700 > message: > Bug#48295: explain extended crash with subquery and ONLY_FULL_GROUP_BY sql_mode > > If an outer query is broken, a subquery might not even get set up. > EXPLAIN EXTENDED did not expect this and merrily tried to de-ref all > of the half-setup info. > > We now catch this case and print as much as we have, as it doesn't cost us > anything (doesn't make regular execution slower).
-
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: 3148.13.4 > revision-id: svoj@sun.com-20091102144320-0hz2ti21em510ee5 > parent: svoj@sun.com-20091102144140-8de1z6mdy5dopw3j > committer: Sergey Vojtovich <svoj@sun.com> > branch nick: mysql-5.1-bugteam > timestamp: Mon 2009-11-02 18:43:20 +0400 > message: > Applying InnoDB snashot 5.1-ss6129 > > Detailed revision comments: > > r6051 | sunny | 2009-10-12 07:05:00 +0300 (Mon, 12 Oct 2009) | 6 lines > branches/5.1: Ignore negative values supplied by the user when calculating the > next value to store in dict_table_t. Setting autoincrement columns top negative > values is undefined behavior and this change should bring the behavior of > InnoDB closer to what users expect. Added several tests to check. > rb://162
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 3148.13.3 > revision-id: svoj@sun.com-20091102144140-8de1z6mdy5dopw3j > parent: svoj@sun.com-20091102143655-lo69f57p82nky58q > committer: Sergey Vojtovich <svoj@sun.com> > branch nick: mysql-5.1-bugteam > timestamp: Mon 2009-11-02 18:41:40 +0400 > message: > Applying InnoDB snashot 5.1-ss6129 > > Detailed revision comments: > > r6045 | jyang | 2009-10-08 02:27:08 +0300 (Thu, 08 Oct 2009) | 7 lines > branches/5.1: Fix bug #47777. Treat the Geometry data same as > Binary BLOB in ha_innobase::store_key_val_for_row(), since the > Geometry data is stored as Binary BLOB in Innodb. > > Review: rb://180 approved by Marko Makela.
-
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.3961.12 > revision-id: li-bing.song@sun.com-20091103090041-zj7nedx6ok5jgges > parent: davi.arnaut@sun.com-20091102201021-1brn7cjb1kvqg9gr > committer: <Li-Bing.Song@sun.com> > branch nick: mysql-5.0-bugteam > timestamp: Tue 2009-11-03 17:00:41 +0800 > message: > BUG#48216 Replication fails on all slaves after upgrade to 5.0.86 on master > > When a sessione is closed, all temporary tables of the session are automatically > dropped and are binlogged. But it will be binlogged with wrong database names when > the length of the temporary tables' database names are greater than the > length of the current database name or the current database is not set. > > Query_log_event's db_len is forgot to set when Query_log_event's db is set. > This patch wrote code to set db_len immediately after db has set.
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 1810.3959.6 > revision-id: joro@sun.com-20091021084345-iki6z0uceieoupey > parent: ramil@mysql.com-20091023112648-gie6o3odj57cxh1e > committer: Georgi Kodinov <joro@sun.com> > branch nick: B47780-5.0-bugteam > timestamp: Wed 2009-10-21 11:43:45 +0300 > message: > Bug #47780: crash when comparing GIS items from subquery > > If the first argument to GeomFromWKB function is a geometry > field then the function just returns its value. > However in doing so it's not preserving first argument's > null_value flag and this causes unexpected null value to > be returned to the calling function. > > Fixed by updating the null_value of the GeomFromWKB function > in such cases (and all other cases that return a NULL e.g. > because of not enough memory for the return buffer).
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 1810.3959.5 > revision-id: ramil@mysql.com-20091023112648-gie6o3odj57cxh1e > parent: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c > committer: Ramil Kalimullin <ramil@mysql.com> > branch nick: b48258-5.0-bugteam > timestamp: Fri 2009-10-23 16:26:48 +0500 > message: > Fix for bug#48258: Assertion failed when using a spatial index > > Problem: involving a spatial index for "non-spatial" queries > (that don't containt MBRXXX() functions) may lead to failed assert. > > Fix: don't use spatial indexes in such cases.
-
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.
-
Kent Boortz authored
-
- 06 Oct, 2009 9 commits
-
-
Bjorn Munch authored
-
Georgi Kodinov authored
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
The pthread_cond_wait implementations for windows might dead lock in some rare circumstances. 1) One thread (I) enter a timed wait and at a point in time ends up after mutex unlock and before WaitForMultipleObjects(...) 2) Another thread (II) enters pthread_cond_broadcast. Grabs the mutex and discovers one waiter. It set the broadcast event and closes the broadcast gate then unlocks the mutex. 3) A third thread (III) issues a pthread_cond_signal. It grabs the mutex, discovers one waiter, sets the signal event then unlock the mutex. 4) The first threads (I) enters WaitForMultipleObjects and finds out that the signal object is in a signalled state and exits the wait. 5) Thread (I) grabs the mutex and checks result status. The number of waiters is decreased and becomes equal to 0. The event returned was a signal event so the broadcast gate isn't opened. The mutex is released. 6) Thread (II) issues a new broadcast. The mutex is acquired but the number of waiters are 0 hence the broadcast gate remains closed. 7) Thread (I) enters the wait again but is blocked by the broadcast gate. This fix resolves the above issue by always resetting broadcast gate when there are no more waiters in th queue. mysys/my_wincond.c: * Always reset the broadcast gate if there are no more waiters left.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 05 Oct, 2009 8 commits
-
-
John H. Embretsen authored
Mask part of EXPLAIN output with '#' to account for varying row count estimation. mysql-test/include/mix1.inc: Mask 'rows' column in EXPLAIN output (number varies sometimes between 1 and 2). mysql-test/r/innodb_mysql.result: Update result file after masking of rows estimation in EXPLAIN output.
-
Frazer Clement authored
-
Frazer Clement authored
-
Satya B authored
1. BUG#46256 - drop table with unknown collation crashes innodb Note: No testcase attached and has to be verified manually Detailed revision comments: r5799 | calvin | 2009-09-09 20:47:31 +0300 (Wed, 09 Sep 2009) | 10 lines branches/5.1: fix bug#46256 Allow tables to be dropped even if the collation is not found, but issue a warning. Could not find an easy way to add mysql-test since it requires changes to charsets and restarting the server. Tests were executed manually. Approved by: Heikki (on IM) r5805 | vasil | 2009-09-10 08:41:48 +0300 (Thu, 10 Sep 2009) | 7 lines branches/5.1: Fix a compilation warning caused by c5799: handler/ha_innodb.cc: In function 'void innobase_get_cset_width(ulint, ulint*, ulint*)': handler/ha_innodb.cc:830: warning: format '%d' expects type 'int', but argument 2 has type 'ulint'
-
Satya B authored
BUG#44369 - InnoDB: Does not uniformly disallow disallowed column names Detailed revision comments: r5741 | jyang | 2009-09-03 07:16:01 +0300 (Thu, 03 Sep 2009) | 5 lines branches/5.1: Block creating table with column name conflicting with Innodb reserved key words. (Bug #44369) rb://151 approved by Sunny Bains. r5760 | jyang | 2009-09-04 07:07:34 +0300 (Fri, 04 Sep 2009) | 3 lines branches/5.1: This is to revert change 5741. A return status for create_table_def() needs to be fixed. r5834 | jyang | 2009-09-11 00:43:05 +0300 (Fri, 11 Sep 2009) | 5 lines branches/5.1: Block creating table with column name conflicting with Innodb reserved key words. (Bug #44369) rb://151 approved by Sunny Bains.
-
Satya B authored
1. BUG#46000 - using index called GEN_CLUST_INDEX crashes server Detailed revision comments: r5895 | jyang | 2009-09-15 03:39:21 +0300 (Tue, 15 Sep 2009) | 5 lines branches/5.1: Disallow creating index with the name of "GEN_CLUST_INDEX" which is reserved for the default system primary index. (Bug #46000) rb://149 approved by Marko Makela.
-
Georgi Kodinov authored
-
Gleb Shchepa authored
SELECT ... WHERE ... IN (NULL, ...) does full table scan, even if the same query without the NULL uses efficient range scan. The bugfix for the bug 18360 introduced an optimization: if 1) all right-hand arguments of the IN function are constants 2) result types of all right argument items are compatible enough to use the same single comparison function to compare all of them to the left argument, then we can convert the right-hand list of constant items to an array of equally-typed constant values for the further QUICK index access etc. (see Item_func_in::fix_length_and_dec()). The Item_null constant item objects have STRING_RESULT result types, so, as far as Item_func_in::fix_length_and_dec() is aware of NULLs in the right list, this improvement efficiently optimizes IN function calls with a mixed right list of NULLs and string constants. However, the optimization doesn't affect mixed lists of NULLs and integers, floats etc., because there is no unique common comparator. New optimization has been added to ignore the result type of NULL constants in the static analysis of mixed right-hand lists. This is safe, because at the execution phase we care about presence of NULLs anyway. 1. The collect_cmp_types() function has been modified to optionally ignore NULL constants in the item list. 2. NULL-skipping code of the Item_func_in::fix_length_and_dec() function has been modified to work not only with in_string vectors but with in_vectors of other types. mysql-test/r/func_in.result: Added test case for the bug #44139. mysql-test/t/func_in.test: Added test case for the bug #44139. sql/item_cmpfunc.cc: Bug #44139: Table scan when NULL appears in IN clause 1. The collect_cmp_types() function has been modified to optionally ignore NULL constants in the item list. 2. NULL-skipping code of the Item_func_in::fix_length_and_dec() function has been modified to work not only with in_string vectors but with in_vectors of other types.
-
- 04 Oct, 2009 7 commits
-
-
Georgi Kodinov authored
rpl.rpl_trigger.test fails with valgrind errors with the innodb plugin
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 02 Oct, 2009 2 commits
-
-
Jonathan Perkin authored
-
Ingo Struewing authored
-