- 01 Jun, 2010 10 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
-
Mattias Jonsson authored
-
Mattias Jonsson authored
result file differs on embedded
-
- 31 May, 2010 5 commits
-
-
Sergey Glukhov authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
Field_time::get_date method does not initialize MYSQL_TIME::time_type field. The fix is to init this field.
-
Vasil Dimov authored
-
Vasil Dimov authored
-
- 28 May, 2010 5 commits
-
-
Jimmy Yang authored
err_index could be not a member of the share structure or prebuilt structure passed from MySQL. For now, we resort to the traditional way of scanning index->table for the index number.
-
Mattias Jonsson authored
(Added a real error message instead of ER_UNKNOWN_ERROR)
-
Mattias Jonsson authored
-
- 27 May, 2010 9 commits
-
-
Dmitry Lenev authored
"Embedded SELECT without FOR UPDATE is causing a lock" into 5.5 tree. One of 5.5 trees already contains a more thorough version of the fix.
-
Dmitry Lenev authored
without FOR UPDATE is causing a lock". SELECT statements with subqueries referencing InnoDB tables were acquiring shared locks on rows in these tables when they were executed in REPEATABLE-READ mode and with statement or mixed mode binary logging turned on. This was a regression which were introduced when fixing bug 39843. The problem was that for tables belonging to subqueries parser set TL_READ_DEFAULT as a lock type. In cases when statement/mixed binary logging at open_tables() time this type of lock was converted to TL_READ_NO_INSERT lock at open_tables() time and caused InnoDB engine to acquire shared locks on reads from these tables. Although in some cases such behavior was correct (e.g. for subqueries in DELETE) in case of SELECT it has caused unnecessary locking. This patch implements minimal version of the fix for the specific problem described in the bug-report which supposed to be not too risky for pushing into 5.1 tree. The 5.5 tree already contains a more appropriate solution which also addresses other related issues like bug 53921 "Wrong locks for SELECTs used stored functions may lead to broken SBR". This patch tries to solve the problem by ensuring that TL_READ_DEFAULT lock which is set in the parser for tables participating in subqueries at open_tables() time is interpreted as TL_READ_NO_INSERT or TL_READ. TL_READ is used only if we know that this is a SELECT and that this particular table is not used by a stored function. Test coverage is added for both InnoDB and MyISAM. This patch introduces an "incompatible" change in locking scheme for subqueries used in SELECT ... FOR UPDATE and SELECT .. IN SHARE MODE. In 4.1 (as well as in 5.0 and 5.1 before fix for bug 39843) the server would use a snapshot InnoDB read for subqueries in SELECT FOR UPDATE and SELECT .. IN SHARE MODE statements, regardless of whether the binary log is on or off. If the user required a different type of read (i.e. locking read), he/she could request so explicitly by providing FOR UPDATE/IN SHARE MODE clause for each individual subquery. The patch for bug 39843 broke this behaviour (which was not documented or tested), and started to use locking reads for all subqueries in SELECT ... FOR UPDATE/IN SHARE MODE. This patch restores 4.1 behaviour. This patch should be mostly null-merged into 5.5 tree.
-
Inaam Rana authored
list a thread doing a wait_ex as an s-lock waiter.
-
Sergey Glukhov authored
-
Sergey Glukhov authored
There are two problems: 1. In simplify_joins function we calculate table dependencies. If STRAIGHT_JOIN hint is used for whole SELECT we do not count it and as result some dependendecies might be lost. It leads to incorrect table order which is returned by join_tab_cmp_straight() function. 2. make_join_statistics() calculate the transitive closure for relations a particular JOIN_TAB is 'dependent on'. We aggregate the dependent table_map of a JOIN_TAB by adding dependencies from other tables which we depend on. However, this may also cause new dependencies to be available after we have completed processing a certain JOIN_TAB. Both these problems affect condition pushdown and as result condition might be pushed into wrong table which leads to crash or even omitted which leads to wrong result. The fix: 1. Use modified 'transitive closure' algorithm provided by Ole John Aske 2. Update table dependences in simplify_joins according to global STRAIGHT_JOIN hint. Note: the patch also fixes bugs 46091 & 51492
-
Alexey Kopytov authored
-
Alexey Kopytov authored
Null-merged patch for bug 53907. Conflicts: conflict sql/sql_parse.cc
-
Alexey Kopytov authored
-
Alexey Kopytov authored
-
- 26 May, 2010 5 commits
-
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
Removed misleading comments.
-
Jimmy Yang authored
-
Jimmy Yang authored
after fast alter table added unique key". Look up MySQL index number should go through index translation table. rb://347, approved by Marko
-
- 25 May, 2010 6 commits
-
-
Ramil Kalimullin authored
-
Alexey Kopytov authored
bitmap_is_set(table->read_set, field_index)) UPDATE on an InnoDB table modifying the same index that is used to satisfy the WHERE condition could trigger a debug assertion under some circumstances. Since for engines with the HA_PRIMARY_KEY_IN_READ_INDEX flag set results of an index scan on a secondary index are appended by the primary key value, if a query involves only columns from the primary key and a secondary index, the latter is considered to be covering. That tricks mysql_update() to mark for reading only columns from the secondary index when it does an index scan to retrieve rows to update in case a part of that key is also being updated. However, there may be other columns in WHERE that are part of the primary key, but not the secondary one. What we actually want to do in this case is to add index columns to the existing WHERE columns bitmap rather than replace it.
-
Vasil Dimov authored
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
Problem: one with SELECT privilege on some table may dump other table performing COM_TABLE_DUMP command due to missed check of the table name. Fix: check the table name.
-
Mattias Jonsson authored
-