- 17 Feb, 2010 5 commits
-
-
Timothy Smith authored
-
Timothy Smith authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
Table corruption happens during table reading in ha_tina::find_current_row() func. Field::store() method returns error(true) if stored value is 0. The fix: added special case for enum type which correctly processes 0 value. Additional fix: INSERT...(default) and INSERT...() have the same behaviour now for enum type.
-
Joerg Bruehe authored
A "%define" is no shell command, so it must not be the only line in the "then" or "else" branch of an "if". Add a ':' line to make the branch non-empty.
-
- 16 Feb, 2010 4 commits
-
-
Mattias Jonsson authored
due to ifdef of include file
-
Sergey Glukhov authored
-
Sergey Glukhov authored
The problem is that during temporary table creation uneven bits are not taken into account for hidden fields. It leads to incorrect calculation&allocation of null bytes size for table record. And if grouped value is null we set wrong bit for this value(see end_update()). Fixed by adding separate calculation of uneven bit for hidden fields.
-
Mattias Jonsson authored
-
- 15 Feb, 2010 1 commit
-
-
Georgi Kodinov authored
Fixed a compilation warning.
-
- 13 Feb, 2010 1 commit
-
-
Davi Arnaut authored
This bug is just one facet of stored routines not being able to detect changes in meta-data (WL#4179). This particular problem can be triggered within a single session due to the improper management of the pre-locking list if the view is expanded after the pre-locking list is calculated. Since the overall solution for the meta-data detection issue is planned for a later release, for now a workaround is used to fix this particular aspect that only involves a single session. The workaround is to flush the thread-local stored routine cache every time a view is created or modified, causing locally cached routines to be re-evaluated upon invocation.
-
- 12 Feb, 2010 2 commits
-
-
Joerg Bruehe authored
-
Mattias Jonsson authored
-
- 10 Feb, 2010 2 commits
-
-
Luis Soares authored
-
Sergey Glukhov authored
The problem becomes apparent only if HAVE_purify is undefined. It related to the part of code placed in open_table_from_share() fuction where we initialize record buffer only if HAVE_purify is enabled. So in case of HAVE_purify=OFF record buffer is not initialized on open table stage. Next we read key, find NULL value and update appropriate null bit but do not update record buffer. After that the record is stored in the join cache(store_record_in_cache). For CHAR fields we strip trailing spaces and in our case this procedure uses uninitialized record buffer. The fix is to skip stripping space procedure in case of null values for CHAR fields(partially based on 6.0 JOIN_CACHE implementation).
-
- 09 Feb, 2010 5 commits
-
-
Sergey Vojtovich authored
-
Sergey Vojtovich authored
-
Sergey Vojtovich authored
-
Magne Mahre authored
removed in MySQL 6.0 CREATE TABLE... TYPE= returns the warning "The syntax 'TYPE=storage_engine' is deprecated and will be removed in MySQL 6.0. Please use 'ENGINE=storage_engine' instead" This syntax is deprecated already from version 5.4.4, so the message has been changed. In addition, the deprecation macro was changed to reflect the ServerPT decision not to include version number in the warning message. A number of test result files have been changed as a consequence of the change in the deprecation macro.
-
Sergey Vojtovich authored
Queries optimized with GROUP_MIN_MAX didn't cleanup KEYREAD optimization properly. As a result subsequent queries may return incomplete rows (fields are initialized to default values).
-
- 07 Feb, 2010 1 commit
-
-
Luis Soares authored
logging is disabled Post-push fix: disabling test when running mysqld in embedded mode.
-
- 06 Feb, 2010 1 commit
-
-
Gleb Shchepa authored
Grouping by a subquery in a query with a distinct aggregate function lead to a wrong result (wrong and unordered grouping values). There are two related problems: 1) The query like this: SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c FROM t1 GROUP BY aa returned wrong result, because the outer reference "t1.a" in the subquery was substituted with the Item_ref item. The Item_ref item obtains data from the result_field object that refreshes once after the end of each group. This data is not applicable to filesort since filesort() doesn't care about groups (and doesn't update result_field objects with copy_fields() and so on). Also that data is not applicable to group separation algorithm: end_send_group() checks every record with test_if_group_changed() that evaluates Item_ref items, but it refreshes those Item_ref-s only after the end of group, that is a vicious circle and the grouped column values in the output are shifted. Fix: if a) we grouping by a subquery and b) that subquery has outer references to FROM list of the grouping query, then we substitute these outer references with Item_direct_ref like references under aggregate functions: Item_direct_ref obtains data directly from the current record. 2) The query with a non-trivial grouping expression like: SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c FROM t1 GROUP BY aa+0 also returned wrong result, since JOIN::exec() substitutes references to top-level aliases in SELECT list with Item_copy caching items. Item_copy items have same refreshing policy as Item_ref items, so the whole groping expression with Item_copy inside returns wrong result in filesort() and end_send_group(). Fix: include aliased items into GROUP BY item tree instead of Item_ref references to them.
-
- 05 Feb, 2010 3 commits
-
-
Luis Soares authored
logging is disabled The server would hit an assertion because of a DBUG violation. There was a missing DBUG_RETURN and instead a plain return was used. This patch replaces the return with DBUG_RETURN.
-
Luis Soares authored
into slow log While processing a statement, down the mysql_parse execution stack, the thd->enable_slow_log can be assigned to opt_log_slow_admin_statements, depending whether one is executing administrative statements, such as ALTER TABLE, OPTIMIZE, ANALYZE, etc, or not. This can have an impact on slow logging for statements that are executed after an administrative statement execution is completed. When executing statements directly from the user this is fine because, the thd->enable_slow_log is reset right at the beginning of the dispatch_command function, ie, everytime a new statement is set is set to execute. On the other hand, for slave SQL thread (sql_thd) the story is a bit different. When in SBR the sql_thd applies statements by calling mysql_parse. Right after, it calls log_slow_statement function to log them if they take too long. Calling mysql_parse directly is fine, but also means that dispatch_command function is bypassed. As a consequence, thd->enable_slow_log does not get a chance to be reset before the next statement to be executed by the sql_thd. If the statement just executed by the sql_thd was an administrative statement and logging of admin statements was disabled, this means that sql_thd->enable_slow_log will be set to 0 (disabled) from that moment on. End result: sql_thd stops logging slow statements. We fix this by resetting the value of sql_thd->enable_slow_log to the value of opt_log_slow_slave_statements right after log_slow_stement is called by the sql_thd.
-
Luis Soares authored
To 5.x Release Notes ===== This is a backport of BUG#23300 into 5.1 GA. Original cset revid (in betony): luis.soares@sun.com-20090929140901-s4kjtl3iiyy4ls2h Description =========== When using replication, the slave will not log any slow query logs queries replicated from the master, even if the option "--log-slow-slave-statements" is set and these take more than "log_query_time" to execute. In order to log slow queries in replicated thread one needs to set the --log-slow-slave-statements, so that the SQL thread is initialized with the correct switch. Although setting this flag correctly configures the slave thread option to log slow queries, there is an issue with the condition that is used to check whether to log the slow query or not. When replaying binlog events the statement contains the SET TIMESTAMP clause which will force the slow logging condition check to fail. Consequently, the slow query logging will not take place. This patch addresses this issue by removing the second condition from the log_slow_statements as it prevents slow queries to be binlogged and seems to be deprecated.
-
- 04 Feb, 2010 1 commit
-
-
Luis Soares authored
When using MyIsam tables and processing concurrent DML statements, the server may be sending back an OK to the client before actually finishing the transaction commit procedure. This has been reported before in BUG@37521 and BUG@29334. This particular test case gets affected, because it performs the following sequence: connect (conn2, ...) connection conn2; LOAD DATA CONCURRENT ... disconnect (conn2, ...) connection master; sync_slave_with_master diff_tables At this point diff_tables may report difference in the table content (the master seems to be missing the conn2 rows). To workaround this MyISAM concurrent DML statements issue and make this test case deterministic, we wait on conn2 until the rows inserted show up in the table. After this the test case proceeds as normally would before this patch.
-
- 03 Feb, 2010 1 commit
-
-
Georgi Kodinov authored
-
- 02 Feb, 2010 4 commits
-
-
Kent Boortz authored
path names than 99 characters, using the USTAR format of the resulting source TAR. To be able to specify the use of USTAR when creating the source TAR, we needed both to update the GNU autotools version requirements slightly, and update the initiation of the tools to use more modern constructs.
-
Joerg Bruehe authored
Get rid of trailing blanks.
-
Joerg Bruehe authored
Cleanup, formatting improvements, vendor is Sun (since MySQL AB was bought). Backport the change so that RPM doesn't magically create a dependency on "Perl-DBI".
-
Sergey Vojtovich authored
Performing fulltext prefix search (a word with truncation operator) may cause a dead-loop. ft_min_word_len value doesn't matter actually. The problem was introduced along with "smarter index merge" optimization.
-
- 01 Feb, 2010 2 commits
-
-
Mattias Jonsson authored
There was two problems: The first was the symptom, caused by bad error handling in ha_partition. It did not handle print_error etc. when having no partitions (when used by dummy handler). The second was the real problem that when dropping tables it reused the table type (storage engine) from when the lock was asked for, not the table type that it had when gaining the exclusive name lock. So that it tried to delete tables from wrong storage engines. Solutions for the first problem was to accept some handler calls to the partitioning handler even if it was not setup with any partitions, and also if possible fallback to use the base handler's default functions. Solution for the second problem was to remove the optimization to reuse the definition from the cache, instead always check the frm-file when holding the LOCK_open mutex (updated with a fix for a debug print crash and better comments as required by reviewer, and removed optimization to avoid reading the frm-file).
-
Georgi Kodinov authored
-
- 29 Jan, 2010 1 commit
-
-
Georgi Kodinov authored
Fixed 2 problems : 1. test_if_order_by_key() was continuing on the primary key as if it has a primary key suffix (as the secondary keys do). This leads to crashes in ORDER BY <pk>,<pk>. Fixed by not treating the primary key as the secondary one and not depending on it being clustered with a primary key. 2. The cost calculation was trying to read the records per key when operating on ORDER BYs that order on all of the secondary key + some of the primary key. This leads to crashes because of out-of-bounds array access. Fixed by assuming we'll find 1 record per key in such cases.
-
- 05 Feb, 2010 1 commit
-
-
Davi Arnaut authored
The problem was that the dbug facility was being used after the per-thread dbug state had already been finalized. The was present in a few functions which invoked decrement_handler_count, which in turn invokes my_thread_end on Windows. In my_thread_end, the per-thread dbug state is finalized. Any use after the state is finalized ends up creating a new state. The solution is to process the exit of a function before the decrement_handler_count function is called.
-
- 29 Jan, 2010 2 commits
-
-
Georgi Kodinov authored
Updated the certs to expire on 2015. Made sure they work with both yassl and openssl.
-
Ramil Kalimullin authored
column is used for ORDER BY Problem: filesort isn't meant for null length sort data (e.g. char(0)), that leads to a server crash. Fix: disregard sort order if sort data record length is 0 (nothing to sort).
-
- 28 Jan, 2010 1 commit
-
-
Davi Arnaut authored
The problem was that a DROP TRIGGER statement inside a stored procedure could cause a crash in subsequent invocations. This was due to the addition, on the first execution, of a temporary table reference to the stored procedure query table list. In a subsequent invocation, there would be a attempt to reinitialize the temporary table reference, which by then was already gone. The solution is to backup and reset the query table list each time a trigger needs to be dropped. This ensures that any temp changes to the query table list are discarded. It is safe to do so at this time as drop trigger is restricted from more complicated scenarios (ie, not allowed within stored functions, etc).
-
- 12 Feb, 2010 2 commits
-
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-