- 19 Jul, 2007 4 commits
-
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/29687/my50-29687
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/29687/my50-29687
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
- 18 Jul, 2007 3 commits
-
-
gshchepa/uchum@gleb.loc authored
For each view the mysqldump utility creates a temporary table with the same name and the same columns as the view in order to satisfy views that depend on this view. After the creation of all tables, mysqldump drops all temporary tables and creates actual views. However, --skip-add-drop-table and --compact flags disable DROP TABLE statements for those temporary tables. Thus, it was impossible to create the views because of existence of the temporary tables with the same names.
-
gkodinov/kgeorge@magare.gmz authored
table (datadir) Set errno when retunring an error in my_create_with_symlink.
-
sergefp@mysql.com authored
-
- 17 Jul, 2007 5 commits
-
-
sergefp@mysql.com authored
-
sergefp@mysql.com authored
-
sergefp@pylon64.mylan authored
into mysql.com:/home/psergey/mysql-5.0-bug29740
-
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.
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
- 16 Jul, 2007 5 commits
-
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.(none) authored
selected prior: ensure the fix also works for information_schema tables.
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-axmrg
-
holyfoot/hf@mysql.com/hfmain.(none) authored
In embedded server we use result->alloc to store field data for the result, but we didn't clean the result->alloc if the query returned an empty recordset. Cleaning for the empty recordset enabled
-
-
- 15 Jul, 2007 5 commits
-
-
evgen@moonbone.local authored
A typo fixed.
-
evgen@moonbone.local authored
Fixed compiler warning.
-
evgen@moonbone.local authored
A comment changed.
-
evgen@moonbone.local authored
The get_time_value function is added. It is used to obtain TIME values both from items the can return time as an integer and from items that can return time only as a string. The Arg_comparator::compare_datetime function now uses pointer to a getter function to obtain values to compare. Now this function is also used for comparison of TIME values. The get_value_func variable is added to the Arg_comparator class. It points to a getter function for the DATE/DATETIME/TIME comparator.
-
kostja@bodhi.(none) authored
Linux Debug build (possible deadlock)" The bug is not repeatable any more.
-
- 14 Jul, 2007 9 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/29729-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
The Field_newdate::store when storing a DATETIME value was returning the 'value was cut' error even if the thd->count_cuted_fields flag is set to CHECK_FIELD_IGNORE. This made range optimizr think that there is no appropriate data in the table and thus to return an empty set. Now the Field_newdate::store function returns conversion error only if the thd->count_cuted_fields flag isn't set to CHECK_FIELD_IGNORE.
-
sergefp@mysql.com authored
-
sergefp@pylon64.mylan authored
into mysql.com:/home/psergey/mysql-5.0-bug29740
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-axmrg
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-axmrg
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-axmrg
-
svoj@mysql.com/april.(none) authored
pseudo_thread_id was reset to zero via mysql_change_user() handling whereas there is no reason to do that. Moreover, having two concurrent threads that change user and create a namesake temp tables leads to recording the dup pair of queries: set @@session.pseudo_thread_id = 0; CREATE temporary table `the namesake`; which will stall the slave as the second instance can not be created. And that is the bug case. Fixed by correcting pseudo_thread_id value after mysql_change_user().
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-merge
-
- 13 Jul, 2007 4 commits
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
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.
-
gkodinov/kgeorge@magare.gmz authored
-
gkodinov/kgeorge@magare.gmz authored
-
- 12 Jul, 2007 5 commits
-
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.(none) authored
incomplete in 5.0 (and review fixes). When in 5.0.13 I introduced class Prepared_statement and methods ::prepare and ::execute, general logging was left out of this class. This was good for stored procedures, since in stored procedures we do not log sub-statements, but introduced a regression in case of SQL syntax for prepared statements, as previously we would log the actual statements to the log, and after the change we would log only COM_QUERY text. Restore the old behavior, but still suppress logging if inside a stored procedure. Based on a community contributed patch from Vladimir Shebordaev. No test case since we do not have a mechanism to test output of the general log.
-
evgen@moonbone.local authored
Time values were compared by the BETWEEN function as strings. This led to a wrong result in cases when some of arguments are less than 100 hours and other are greater. Now if all 3 arguments of the BETWEEN function are of the TIME type then they are compared as integers.
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-26141-final
-
kostja@bodhi.(none) authored
causes full table lock on innodb table. Also fixes Bug#28502 Triggers that update another innodb table will block on X lock unnecessarily (duplciate). Code review fixes. Both bugs' synopses are misleading: InnoDB table is not X locked. The statements, however, cannot proceed concurrently, but this happens due to lock conflicts for tables used in triggers, not for the InnoDB table. If a user had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (e.g. two distinct MyISAM tables), then these two triggers would not be able to execute concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would not be able to run concurrently. The problem had other side-effects (see respective bug reports). This behavior was a consequence of a shortcoming of the pre-locking algorithm, which would not distinguish between different DML operations (e.g. INSERT and DELETE) and pre-lock all the tables that are used by any trigger defined on the subject table. The idea of the fix is to extend the pre-locking algorithm to keep track, for each table, what DML operation it is used for and not load triggers that are known to never be fired.
-