- 21 Feb, 2010 1 commit
-
-
Alexey Kopytov authored
-
- 18 Feb, 2010 1 commit
-
-
Georgi Kodinov authored
Fixed the test to behave correctly with ps-protocol and binlog format row.
-
- 17 Feb, 2010 3 commits
-
-
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 1 commit
-
-
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 8 commits
-
-
Alexander Nozdrin authored
-
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.
-
Alexander Nozdrin authored
-
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).
-
Alexey Kopytov authored
Conflicts: Text conflict in .bzr-mysql/default.conf Text conflict in mysql-test/suite/rpl/r/rpl_slow_query_log.result Text conflict in mysql-test/suite/rpl/t/rpl_slow_query_log.test Conflict adding files to server-tools. Created directory. Conflict because server-tools is not versioned, but has versioned children. Versioned directory. Conflict adding files to server-tools/instance-manager. Created directory. Conflict because server-tools/instance-manager is not versioned, but has versioned children. Versioned directory. Contents conflict in server-tools/instance-manager/options.cc Text conflict in sql/mysqld.cc
-
- 08 Feb, 2010 3 commits
-
-
Joerg Bruehe authored
fixing bug#50950.
-
Joerg Bruehe authored
fixing bug#50950.
-
Joerg Bruehe authored
in message printed at end of configure New text for the success message of "configure".
-
- 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 5 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.
-
Alexander Nozdrin authored
Original revision: ------------------------------------------------------------ revision-id: kent.boortz@sun.com-20100204182709-dw1dwpglkd5qrehb committer: Kent Boortz <kent.boortz@sun.com> branch nick: mysql-5.1-bugteam timestamp: Thu 2010-02-04 19:27:09 +0100 message: LT_INIT and LT_PREREQ was added in libtool 2.2 2008, a bit too recent, switched back to the older AC_PROG_LIBTOOL ------------------------------------------------------------
-
Alexander Nozdrin authored
-
- 04 Feb, 2010 4 commits
-
-
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.
-
hery.ramilison@sun.com authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 03 Feb, 2010 4 commits
-
-
Alexander Nozdrin authored
Conflicts: - configure.in - mysql-test/include/setup_fake_relay_log.inc - sql/sql_select.cc
-
Alexander Nozdrin authored
Conflicts: - sql/mysqld.cc
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-