- 17 Nov, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
Comparison of a BIGINT NOT NULL column with a constant arithmetic expression that evaluates to NULL caused error 1048: "Column '...' cannot be null". Made convert_constant_item() check if the constant expression is NULL before attempting to store it in a field. Attempts to store NULL in a NOT NULL field caused query errors.
-
- 16 Nov, 2007 4 commits
-
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
kaa@polly.(none) authored
checked for each record' The problem was in incorrectly calculated length of the buffer used to store a hexadecimal representation of an index map in select_describe(). This could result in buffer overrun and stack corruption under some circumstances. Fixed by correcting the calculation.
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gluh@mysql.com/eagle.(none) authored
Implement neccessary shared lock structure for table locks. This is the backport of bug26241 fix.
-
- 15 Nov, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B31928-5.0-opt
-
- 14 Nov, 2007 4 commits
-
-
gluh@mysql.com/eagle.(none) authored
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/4.1-opt
-
- 13 Nov, 2007 5 commits
-
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/31305/my50-31305
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/31305/my50-31305
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/31305/my41-31305
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B31562-5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
The columns in HAVING can reference the GROUP BY and SELECT columns. There can be "table" prefixes when referencing these columns. And these "table" prefixes in HAVING use the table alias if available. This means that table aliases are subject to the same storage rules as table names and are dependent on lower_case_table_names in the same way as the table names are. Fixed by : 1. Treating table aliases as table names and make them lowercase when printing out the SQL statement for view persistence. 2. Using case insensitive comparison for table aliases when requested by lower_case_table_names
-
- 12 Nov, 2007 10 commits
-
-
mattiasj@mattiasj-laptop.(none) authored
into mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.0-engines_with_main
-
mattiasj@mattiasj-laptop.(none) authored
into mattiasj-laptop.(none):/home/mattiasj/clones/mysql-5.0-engines_with_main
-
svoj@june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG32111/mysql-5.0-engines
-
svoj@mysql.com/june.mysql.com authored
Use proper variable for test.
-
svoj@june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG32111/mysql-5.0-engines
-
svoj@mysql.com/june.mysql.com authored
-
svoj@mysql.com/june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG32111/mysql-4.1-engines
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/31305/my50-31305
-
holyfoot/hf@mysql.com/hfmain.(none) authored
When we insert a record into MYISAM table which is almost 'full', we first write record data in the free space inside a file, and then check if we have enough space after the end of the file. So if we don't have the space, table will left corrupted. Similar error also happens when we updata MYISAM tables. Fixed by modifying write_dynamic_record and update_dynamic_record functions to check for free space before writing parts of a record
-
- 10 Nov, 2007 10 commits
-
-
tnurnberg@white.intern.koehntopp.de authored
into mysql.com:/misc/mysql/31700/50-31700
-
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
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
gshchepa/uchum@gleb.loc authored
After adding an index the <VARBINARY> IN (SELECT <BINARY> ...) clause returned a wrong result: the VARBINARY value was illegally padded with zero bytes to the length of the BINARY column for the index search. (<VARBINARY>, ...) IN (SELECT <BINARY>, ... ) clauses are affected too.
-
tnurnberg@white.intern.koehntopp.de authored
into mysql.com:/misc/mysql/31700/50-31700
-
UNIQUE (eq-ref) lookups result in table being considered as a "constant" table. Queries that consist of only constant tables are processed in do_select() in a special way that doesn't invoke evaluate_join_record(), and therefore doesn't increase the counters join->examined_rows and join->thd->row_count. The patch increases these counters in this special case. NOTICE: This behavior seems to contradict what the documentation says in Sect. 5.11.4: "Queries handled by the query cache are not added to the slow query log, nor are queries that would not benefit from the presence of an index because the table has zero rows or one row." No test case in 5.0 as issue shows only in slow query log, and other counters can give subtly different values (with regard to counting in create_sort_index(), synthetic rows in ROLLUP, etc.).
-
tnurnberg@white.intern.koehntopp.de authored
into mysql.com:/scratch/tnurnberg/31800/50-31800
-
BETWEEN was more lenient with regard to what it accepted as a DATE/DATETIME in comparisons than greater-than and less-than were. ChangeSet makes < > comparisons similarly robust with regard to trailing garbage (" GMT-1") and "missing" leading zeros. Now all three comparators behave similarly in that they throw a warning for "junk" at the end of the data, but then proceed anyway if possible. Before < > fell back on a string- (rather than date-) comparison when a warning-condition was raised in the string-to-date conversion. Now the fallback only happens on actual errors, while warning- conditions still result in a warning being to delivered to the client.
-
tnurnberg@white.intern.koehntopp.de authored
into mysql.com:/misc/mysql/31990/50-31990
-
- 09 Nov, 2007 3 commits
-
-
kaa@polly.(none) authored
The bug is a regression introduced by the fix for bug30596. The problem was that in cases when groups in GROUP BY correspond to only one row, and there is ORDER BY, the GROUP BY was removed and the ORDER BY rewritten to ORDER BY <group_by_columns> without checking if the columns in GROUP BY and ORDER BY are compatible. This led to incorrect ordering of the result set as it was sorted using the GROUP BY columns. Additionaly, the code discarded ASC/DESC modifiers from ORDER BY even if its columns were compatible with the GROUP BY ones. This patch fixes the regression by checking if ORDER BY columns form a prefix of the GROUP BY ones, and rewriting ORDER BY only in that case, preserving the ASC/DESC modifiers. That check is sufficient, since the GROUP BY columns contain a unique index.
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
kaa@polly.(none) authored
causes out of memory errors The code in mysql_create_function() and mysql_drop_function() assumed that the only reason for UDFs being uninitialized at that point is an out-of-memory error during initialization. However, another possible reason for that is the --skip-grant-tables option in which case UDF initialization is skipped and UDFs are unavailable. The solution is to check whether mysqld is running with --skip-grant-tables and issue a proper error in such a case.
-
- 08 Nov, 2007 2 commits
-
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-