- 29 Sep, 2008 1 commit
-
-
Davi Arnaut authored
The problem is that when statement-based replication was enabled, statements such as INSERT INTO .. SELECT FROM .. and CREATE TABLE .. SELECT FROM need to grab a read lock on the source table that does not permit concurrent inserts, which would in turn be denied if the source table is a log table because log tables can't be locked exclusively. The solution is to not take such a lock when the source table is a log table as it is unsafe to replicate log tables under statement based replication. Furthermore, the read lock that does not permits concurrent inserts is now only taken if statement-based replication is enabled and if the source table is not a log table.
-
- 20 Sep, 2008 1 commit
-
-
Mattias Jonsson authored
-
- 19 Sep, 2008 3 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 18 Sep, 2008 4 commits
-
-
Mattias Jonsson authored
and Bug#33555: Group By Query does not correctly aggregate partitions Backport of bug-33257 which is the same bug. read_range_*() calls was not passed to the partition handlers, but was translated to index_read/next family calls. Resulting in duplicates rows and wrong aggregations.
-
Georgi Kodinov authored
The fix for bug 31887 was incomplete : it assumes that all the field types returned by the IS_NUM macro are descendants of Item_num and tries to zero-fill the values before doing constant substitution with such fields when they are compared to constant string values. The only exception to this is Field_timestamp : it's in the IS_NUM macro, but is not a descendant of Field_num. Fixed by excluding timestamp fields (Field_timestamp) when zero-filling when converting the constant to compare with to a string. Note that this will not exclude the timestamp columns from const propagation.
-
Gleb Shchepa authored
--ps-protocol problem has been fixed.
-
Gleb Shchepa authored
columns data types The "SELECT @lastId, @lastId := Id FROM t" query returns different result sets depending on the type of the Id column (INT or BIGINT). Note: this fix doesn't cover the case when a select query references an user variable and stored function that updates a value of that variable, in this case a result is indeterminate. The server uses incorrect assumption about a constantness of an user variable value as a select list item: The server caches a last query number where that variable was changed and compares this number with a current query number. If these numbers are different, the server guesses, that the variable is not updating in the current query, so a respective select list item is a constant. However, in some common cases the server updates cached query number too late. The server has been modified to memorize user variable assignments during the parse phase to take them into account on the next (query preparation) phase independently of the order of user variable references/assignments in a select item list.
-
- 16 Sep, 2008 2 commits
-
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
- 11 Sep, 2008 3 commits
-
-
Tatiana A. Nurnberg authored
If [NOT] PRESERVE was not given, parser always defaulted to NOT PRESERVE, making it impossible for the "not given = no change" rule to work in ALTER EVENT. Leaving out the PRESERVE-clause defaults to NOT PRESERVE on CREATE now, and to "no change" in ALTER.
-
Tatiana A. Nurnberg authored
mysqldump creates stand-in tables before dumping the actual view. Those tables were of the default type; if the view had more columns than that (a pathological case, arguably), loading the dump would fail. We now make the temporary stand-ins MyISAM tables to prevent this.
-
Tatiana A. Nurnberg authored
mysqldump creates stand-in tables before dumping the actual view. Those tables were of the default type; if the view had more columns than that (a pathological case, arguably), loading the dump would fail. We now make the temporary stand-ins MyISAM tables to prevent this.
-
- 10 Sep, 2008 4 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Evgeny Potemkin authored
-
- 09 Sep, 2008 7 commits
-
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
-
Martin Hansson authored
-
Ramil Kalimullin authored
Problem: <=> operator may return wrong results comparing NULL and a DATE/DATETIME/TIME value. Fix: properly check NULLs.
-
Mats Kindahl authored
-
Martin Hansson authored
statement/stored procedure View privileges are properly checked after the fix for bug no 36086, so the method TABLE_LIST::get_db_name() must be used instead of field TABLE_LIST::db, as this only works for tables. Bug appears when accessing views in prepared statements.
-
Mats Kindahl authored
SUPER is not required to change binlog format for session A user without SUPER privileges can change the value of the session variable BINLOG_FORMAT, causing problems for a DBA. This changeset requires a user to have SUPER privileges to change the value of the session variable BINLOG_FORMAT, and not only the global variable BINLOG_FORMAT.
-
- 08 Sep, 2008 4 commits
-
-
Georgi Kodinov authored
-
Ramil Kalimullin authored
-
Martin Hansson authored
-
Ramil Kalimullin authored
-
- 05 Sep, 2008 9 commits
-
-
Georgi Kodinov authored
SET col When reporting a duplicate key error the server was making incorrect assumptions on what the state of the value string to include in the error is. Fixed by accessing the data in this string in a "safe" way (without relying on it having a terminating 0). Detected by code analysis and fixed a similar problem in reporting the foreign key duplicate errors.
-
Narayanan V authored
-
Narayanan V authored
Added a rule that uses gcc to generate preprocessor output (gcc -E) that can be compared to an already generated output using the diff utility. icheck has been removed and replaced by gcc -E because icheck does not support C++.
-
Georgi Kodinov authored
-
Evgeny Potemkin authored
The check_table_access function initializes per-table grant info and performs access rights check. It wasn't called for SHOW STATUS statement thus left grants info uninitialized. In some cases this led to server crash. In other cases it allowed a user to check for presence/absence of arbitrary values in any tables. Now the check_table_access function is called prior to the statement processing.
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
Problem: SELECT ... REGEXP BINARY NULL may lead to server crash/hang. Fix: properly handle NULL regular expressions.
-
Ramil Kalimullin authored
-
- 04 Sep, 2008 1 commit
-
-
Narayanan V authored
-
- 03 Sep, 2008 1 commit
-
-
Mats Kindahl authored
Incremental fixes: updating a comment and fixing a result file.
-