An error occurred fetching the project authors.
- 27 Nov, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
memory corruptions. The right pointer field of the SEL_ARG structure was not initialized in the constructor and sometimes that led to server crashes. There is no testcase because the bug occurs only when uninitialized memory has particular values, which can't be re-created in the test suite.
-
- 22 Nov, 2007 1 commit
-
-
evgen@moonbone.local authored
Fix for the bug#31048 for 64bit platforms. subselect.test, subselect.result: Corrected text case for the bug#31048.
-
- 19 Nov, 2007 1 commit
-
-
evgen@moonbone.local authored
This bug is actually two. The first one manifests itself on an EXPLAIN SELECT query with nested subqueries that employs the filesort algorithm. The whole SELECT under explain is marked as UNCACHEABLE_EXPLAIN to preserve some temporary structures for explain. As a side-effect of this values of nested subqueries weren't cached and subqueries were re-evaluated many times. Each time buffer for filesort was allocated but wasn't freed because freeing occurs at the end of topmost SELECT. Thus all available memory was eaten up step by step and OOM event occur. The second bug manifests itself on SELECT queries with conditions where a subquery result is compared with a key field and the subquery itself also has such condition. When a long chain of such nested subqueries is present the stack overrun occur. This happens because at some point the range optimizer temporary puts the PARAM structure on the stack. Its size if about 8K and the stack is exhausted very fast. Now the subselect_single_select_engine::exec function allows subquery result caching when the UNCACHEABLE_EXPLAIN flag is set. Now the SQL_SELECT::test_quick_select function calls the check_stack_overrun function for stack checking purposes to prevent server crash.
-
- 23 Oct, 2007 3 commits
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
- 12 Sep, 2007 1 commit
-
-
sergefp@mysql.com authored
-
- 10 Sep, 2007 1 commit
-
-
sergefp@mysql.com authored
in get_index_for_order(), don't walk over the end of the index key parts when matching index description and needed ordering.
-
- 15 Aug, 2007 1 commit
-
-
mhansson/martin@linux-st28.site authored
ORDER BY is used The range analysis module did not correctly signal to the handler that a range represents a ref (EQ_RANGE flag). This causes non-range queries like SELECT ... FROM ... WHERE keypart_1=const, ..., keypart_n=const ORDER BY ... FOR UPDATE to wait for a lock unneccesarily if another running transaction uses SELECT ... FOR UPDATE on the same table. Fixed by setting EQ_RANGE for all range accesses that represent an equality predicate.
-
- 27 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
between perm and temp tables. Review fixes. The original bug report complains that if we locked a temporary table with LOCK TABLES statement, we would not leave LOCK TABLES mode when this temporary table is dropped. Additionally, the bug was escalated when it was discovered than when a temporary transactional table that was previously locked with LOCK TABLES statement was dropped, futher actions with this table, such as UNLOCK TABLES, would lead to a crash. The problem originates from incomplete support of transactional temporary tables. When we added calls to handler::store_lock()/handler::external_lock() to operations that work with such tables, we only covered the normal server code flow and did not cover LOCK TABLES mode. In LOCK TABLES mode, ::external_lock(LOCK) would sometimes be called without matching ::external_lock(UNLOCK), e.g. when a transactional temporary table was dropped. Additionally, this table would be left in the list of LOCKed TABLES. The patch aims to address this inadequacy. Now, whenever an instance of 'handler' is destroyed, we assert that it was priorly external_lock(UNLOCK)-ed. All the places that violate this assert were fixed. This patch introduces no changes in behavior -- the discrepancy in behavior will be fixed when we start calling ::store_lock()/::external_lock() for all tables, regardless whether they are transactional or not, temporary or not.
-
- 17 Jul, 2007 3 commits
-
-
sergefp@mysql.com authored
-
sergefp@mysql.com authored
-
sergefp@mysql.com authored
'/' and '\' in path delimiters: - Fix this by creating new handler with exactly the same path line as was passed to ha_create/ha_open.
-
- 13 Jul, 2007 1 commit
-
-
sergefp@mysql.com authored
- return HA_KEY_SCAN_NOT_ROR flag for HASH indexes; - Fix ha_heap::cmp_ref() to work with BTREE index scans.
-
- 30 Mar, 2007 1 commit
-
-
sergefp@mysql.com authored
Pushbuild fixes: - Make MAX_SEL_ARGS smaller (even 16K records_in_range() calls is more than it makes sense to do in typical cases) - Don't call sel_arg->test_use_count() if we've already allocated more than MAX_SEL_ARGs elements. The test will succeed but will take too much time for the test suite (and not provide much value).
-
- 29 Mar, 2007 1 commit
-
-
sergefp@mysql.com authored
- Post-review fixes
-
- 28 Mar, 2007 1 commit
-
-
sergefp@mysql.com authored
- Added PARAM::alloced_sel_args where we count the # of SEL_ARGs created by SEL_ARG tree cloning operations. - Made the range analyzer to shortcut and not do any more cloning if we've already created MAX_SEL_ARGS SEL_ARG objects in cloning. - Added comments about space complexity of SEL_ARG-graph representation.
-
- 22 Mar, 2007 1 commit
-
-
jani@ua141d10.elisa.omakaista.fi authored
-
- 20 Mar, 2007 1 commit
-
-
gkodinov/kgeorge@macbook.local authored
To correctly decide which predicates can be evaluated with a given table the optimizer must know the exact set of tables that a predicate depends on. If that mask is too wide (refer to non-existing tables) the optimizer can erroneously skip a predicate. One such case of wrong table usage mask were the aggregate functions. The have a all-1 mask (meaning depend on all tables, including non-existent ones). Fixed by making a real used_tables mask for the aggregates. The mask is constructed in the following way : 1. OR the table dependency masks of all the arguments of the aggregate. 2. If all the arguments of the function are from the local name resolution context and it is evaluated in the same name resolution context where it is referenced all the tables from that name resolution context are OR-ed to the dependency mask. This is to denote that an aggregate function depends on the number of rows it processes. 3. Handle correctly the case of an aggregate function optimization (such that the aggregate function can be pre-calculated and made a constant). Made sure that an aggregate function is never a constant (unless subject of a specific optimization and pre-calculation). One other flaw was revealed and fixed in the process : references were not calling the recalculation method for used_tables of their targets.
-
- 10 Mar, 2007 1 commit
-
-
igor@olga.mysql.com authored
Crash happened because the function get_best_group_min_max detected joins with ROLLUP incorrectly.
-
- 12 Feb, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
-
- 11 Feb, 2007 1 commit
-
-
igor@olga.mysql.com authored
A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset caused a crash when a query with DISTINCT was executed by a loose scan for an InnoDB table that had been emptied.
-
- 02 Feb, 2007 1 commit
-
-
igor@olga.mysql.com authored
This performance degradation for UPDATEs could be observed in the update statements for which the search key cannot be converted to any valid value of the type of the search column, like for a the condition int_fld=99999999999999999999999999, though it can be guaranteed here that there is no row with such a key value.
-
- 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.
-
- 31 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Corrected spelling in copyright text Makefile.am: Don't update the files from BitKeeper Many files: Removed "MySQL Finland AB & TCX DataKonsult AB" from copyright header Adjusted year(s) in copyright header Many files: Added GPL copyright text Removed files: Docs/Support/colspec-fix.pl Docs/Support/docbook-fixup.pl Docs/Support/docbook-prefix.pl Docs/Support/docbook-split Docs/Support/make-docbook Docs/Support/make-makefile Docs/Support/test-make-manual Docs/Support/test-make-manual-de Docs/Support/xwf
-
- 26 Dec, 2006 1 commit
-
-
svoj@mysql.com/june.mysql.com authored
repair it Multi-table delete that is optimized with QUICK_RANGE reports table corruption. DELETE statement must not use KEYREAD optimization, and sets table->no_keyread to 1. This was ignored in QUICK_RANGE optimization. With this fix QUICK_RANGE optimization honors table->no_keyread value and does not enable KEYREAD when it is requested.
-
- 23 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Changed header to GPL version 2 only
-
- 14 Dec, 2006 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
- Removed not used variables and functions - Added #ifdef around code that is not used - Renamed variables and functions to avoid conflicts - Removed some not used arguments Fixed some class/struct warnings in ndb Added define IS_LONGDATA() to simplify code in libmysql.c I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
-
- 30 Nov, 2006 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
Fixed compiler warnings (detected by VC++): - Removed not used variables - Added casts - Fixed wrong assignments to bool - Fixed wrong calls with bool arguments - Added missing argument to store(longlong), which caused wrong store method to be called.
-
- 28 Nov, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
statements Currently the optimizer evaluates loose index scan only for top-level SELECT statements Extend loose index scan applicability by : - Test the applicability of loose scan for each sub-select, instead of the whole query. This change enables loose index scan for sub-queries. - allow non-select statements with SELECT parts (like, e.g. CREATE TABLE .. SELECT ...) to use loose index scan.
-
- 27 Nov, 2006 1 commit
-
-
kaa@polly.local authored
When calculating a SEL_TREE for the "c_{i-1} < X < c_i" interval, check if the tree returned for the "-inf < X < c_0" interval is NULL
-
- 20 Nov, 2006 1 commit
-
-
monty@mysql.com/nosik.monty.fi authored
(Mostly in DBUG_PRINT() and unused arguments) Fixed bug in query cache when used with traceing (--with-debug) Fixed memory leak in mysqldump Removed warnings from mysqltest scripts (replaced -- with #)
-
- 19 Oct, 2006 1 commit
-
-
We miss some records sometimes using RANGE method if we have partial key segments. Example: Create table t1(a char(2), key(a(1))); insert into t1 values ('a'), ('xx'); select a from t1 where a > 'x'; We call index_read() passing 'x' key and HA_READ_AFTER_KEY flag in the handler::read_range_first() wich is wrong because we have a partial key segment for the field and might miss records like 'xx'. Fix: don't use open segments in such a case.
-
- 16 Oct, 2006 1 commit
-
-
gkodinov/kgeorge@macbook.gmz authored
When using index for group by and range access the server isolates a set of ranges based on the conditions over the key parts of the index used. Then it uses only the ranges over the GROUP BY fields to jump from one group to another. Since the GROUP BY fields may form a prefix over the index, we may use only a prefix of the ranges produced by the range optimizer. Each range contains a notion on whether it includes its border values. The problem is that when using a range prefix, the last range is open because it assumes that there is a range on the next keypart. Thus when we use a prefix range as it is, it excludes all border values. The solution is when ignoring the suffix of the range conditions (to jump over the GROUP BY prefix only) the server must change the remaining intervals so they always contain their borders, e.g. if the whole range was : (1,-inf) <= (<group_by_col>,<min_max_arg_col>) < (1, 3) we must make (1) <= (<group_by_col>) <= (1) because (a,b) < (c1,c2) means : a < c1 OR (a = c1 AND b < c2).
-
- 21 Sep, 2006 1 commit
-
-
dlenev@mockturtle.local authored
this key does not stop" (version for 5.0 only). UPDATE statement which WHERE clause used key and which invoked trigger that modified field in this key worked indefinetely. This problem occured because in cases when UPDATE statement was executed in update-on-the-fly mode (in which row is updated right during evaluation of select for WHERE clause) the new version of the row became visible to select representing WHERE clause and was updated again and again. We already solve this problem for UPDATE statements which does not invoke triggers by detecting the fact that we are going to update field in key used for scanning and performing update in two steps, during the first step we gather information about the rows to be updated and then doing actual updates. We also do this for MULTI-UPDATE and in its case we even detect situation when such fields are updated in triggers (actually we simply assume that we always update fields used in key if we have before update trigger). The fix simply extends this check which is done in check_if_key_used()/ QUICK_SELECT_I::check_if_keys_used() routine/method in such way that it also detects cases when field used in key is updated in trigger. As nice side-effect we have more precise and thus more optimal perfomance-wise check for the MULTI-UPDATE. Also check_if_key_used()/QUICK_SELECT_I::check_if_keys_used() were renamed to is_key_used()/QUICK_SELECT_I::is_keys_used() in order to better reflect that boolean predicate. Note that this check is implemented in much more elegant way in 5.1
-
- 18 Sep, 2006 1 commit
-
-
gkodinov@dl145s.mysql.com authored
-
- 12 Sep, 2006 1 commit
-
-
svoj@april.(none) authored
Only MyISAM tables locked with LOCK TABLES ... WRITE were affected. A query that is optimized with index_merge doesn't reflect rows inserted within LOCK TABLES. MyISAM doesn't flush a state within LOCK TABLES. index_merge optimization creates a copy of the handler, which thus gets outdated MyISAM state. New handler->clone() method is introduced to fix this problem. For non-MyISAM storage engines it allocates a handler and opens it with ha_open(). For MyISAM it additionally copies MyISAM state pointer to cloned handler.
-
- 31 Aug, 2006 1 commit
-
-
igor@rurik.mysql.com authored
when a range condition use an invalid DATETIME constant. Now we do not use invalid DATETIME constants to form end keys for range intervals: range analysis just ignores predicates with such constants.
-
- 24 Aug, 2006 2 commits
-
-
evgen@sunlight.local authored
Corrected fix for bug#18165
-
evgen@moonbone.local authored
Corrected fix for bug#18165
-