- 18 May, 2008 1 commit
-
-
unknown authored
first row or fails with an error: ERROR 1022 (23000): Can't write; duplicate key in table '' The server uses intermediate temporary table to store updated row data. The first column of this table contains rowid. Current server implementation doesn't reset NULL flag of that column even if the server fills a column with rowid. To keep each rowid unique, there is an unique index. An insertion into an unique index takes into account NULL flag of key value and ignores real data if NULL flag is set. So, insertion of actually different rowids may lead to two kind of problems. Visible effect of each of these problems depends on an initial engine type of temporary table: 1. If multiupdate initially creates temporary table as a MyISAM table (a table contains blob columns, and the create_tmp_table function assumes, that this table is large), it inserts only one single row and updates only rows with one corresponding rowid. Other rows are silently ignored. 2. If multiupdate initially creates MEMORY temporary table, fills it with data and reaches size limit for MEMORY tables (max_heap_table_size), multiupdate converts MEMORY table into MyISAM table and fails with an error: ERROR 1022 (23000): Can't write; duplicate key in table '' Multiupdate has been fixed to update the NULL flag of temporary table rowid columns. mysql-test/r/multi_update_tiny_hash.result: Added test case for bug#36676. mysql-test/t/multi_update_tiny_hash-master.opt: Added test case for bug#36676. mysql-test/t/multi_update_tiny_hash.test: Added test case for bug#36676. sql/sql_update.cc: Fixed bug#36676: multiupdate using LEFT JOIN updates only first row or fails with an error: ERROR 1022 (23000): Can't write; duplicate key in table '' The multi_update::send_data method has been modified to reset null bits of fields containing rowids.
-
- 13 May, 2008 1 commit
-
-
unknown authored
into host.loc:/work/bk/5.0-bugteam
-
- 12 May, 2008 2 commits
-
-
unknown authored
into host.loc:/work/bk/5.0-bugteam
-
unknown authored
The REPAIR TABLE ... USE_FRM query silently corrupts data of tables with old .FRM file version. The mysql_upgrade client program or the REPAIR TABLE query (without the USE_FRM clause) can't prevent this trouble, because in the common case they don't upgrade .FRM file to compatible structure. 1. Evaluation of the REPAIR TABLE ... USE_FRM query has been modified to reject such tables with the message: "Failed repairing incompatible .FRM file". 2. REPAIR TABLE query (without USE_FRM clause) evaluation has been modified to upgrade .FRM files to current version. 3. CHECK TABLE ... FOR UPGRADE query evaluation has been modified to return error status when .FRM file has incompatible version. 4. mysql_upgrade and mysqlcheck client programs call CHECK TABLE FOR UPGRADE and REPAIR TABLE queries, so their behaviors have been changed too to upgrade .FRM files with incompatible version numbers. mysql-test/std_data/bug36055.MYD: Added test data for bug #36055. mysql-test/std_data/bug36055.MYI: Added test data for bug #36055. mysql-test/std_data/bug36055.frm: Added test data for bug #36055. mysql-test/r/repair.result: Added test case for bug# 36055. mysql-test/t/repair.test: Added test case for bug# 36055. sql/handler.cc: Fixed bug #36055: mysql_upgrade doesn't really 'upgrade' tables The handler::ha_check_for_upgrade method has been modified to return error if .FRM file has incompatible version number. sql/sql_table.cc: Fixed bug #36055: mysql_upgrade doesn't really 'upgrade' tables The prepare_for_repair function has been modified to reject REPAIR TABLE ... USE_FRM queries on incompatible .FRM files with the message: "Failed repairing incompatible .FRM file".
-
- 08 May, 2008 2 commits
-
-
unknown authored
into client-10-129-10-147.upp.off.mysql.com:/Users/mattiasj/clones/topush-50-bugteam
-
unknown authored
Problem was that mysql_create_view did not remove all comments characters when writing to binlog, resulting in parse error of stmt on slave side. Solution was to use the recreated select clause and add a generated CHECK OPTION clause if needed. mysql-test/r/rpl_sp.result: Bug#32575 - Parse error of stmt with extended comments on slave side Updated test result mysql-test/r/rpl_view.result: Bug#32575 - Parse error of stmt with extended comments on slave side Updated test result mysql-test/t/rpl_view.test: Bug#32575 - Parse error of stmt with extended comments on slave side Added test case sql/sql_view.cc: Bug#32575 - Parse error of stmt with extended comments on slave side Problem was that mysql_create_view did not remove all comments characters when writing to binlog, resulting in parse error of stmt on slave side. Solution was to use the recreated select clause and generate 'WITH {LOCAL|CASCADED} CHECK OPTION'.
-
- 06 May, 2008 3 commits
-
-
unknown authored
or incorrect. For better conformance with standard, truncation procedure of CHAR columns has been changed to ignore truncation of trailing whitespace characters (note has been removed). Finally, for columns with non-binary charsets: 1. CHAR(N) columns silently ignore trailing whitespace truncation; 2. VARCHAR and TEXT columns issue Note about truncation. BLOBs and other columns with BINARY charset are unaffected. mysql-test/r/bdb.result: Rollback of bug #30059 fix. mysql-test/r/heap.result: Rollback of bug #30059 fix. mysql-test/r/innodb.result: Rollback of bug #30059 fix. mysql-test/r/myisam.result: Rollback of bug #30059 fix. mysql-test/r/strict.result: Rollback of bug #30059 fix. mysql-test/r/type_binary.result: Rollback of bug #30059 fix. mysql-test/r/warnings.result: Updated test case for bug #30059. sql/field.cc: Post-commit fix for bug #30059. The Field_longstr::report_if_important_data method has been changed to notify about trailing spaces only if the new count_spaces parameter is TRUE. The Field_string::store method has been changed to ignore trailing whitespace truncation (CHAR column type). sql/field.h: Post-commit fix for bug #30059. The Field_longstr::report_if_important_data method declaration has been changed to accept extra parameter: bool count_spaces.
-
unknown authored
-
unknown authored
We could allocate chunks larger than 4GB, but did our size-accounting in 32-bit values. This could lead to spurious warnings, inaccurate accounting, and, in theory, data loss. Affected: 64-bit platforms. Debug-build (with safemalloc). At least one buffer larger than 4GB. For potential data loss, a re-alloc on such a buffer would be necessary. mysys/my_static.c: Make memory-accounting 64-bit safe. mysys/my_static.h: Make memory-accounting 64-bit safe. Move in struct for better alignment when 64-bit.
-
- 05 May, 2008 1 commit
-
-
unknown authored
into magare.gmz:/home/kgeorge/mysql/work/merge-5.0-bugteam mysql-test/mysql-test-run.pl: Auto merged
-
- 02 May, 2008 5 commits
-
-
unknown authored
into pilot.mysql.com:/data/msvensson/mysql/mysql-5.0-bugteam client/mysqltest.c: Auto merged
-
unknown authored
client/mysql_upgrade.c: Add --tmpdir option to mysql_upgrade and use it when creating temporary files. mysql-test/mysql-test-run.pl: Pass --tmpdir to mysql_upgrade
-
unknown authored
- Code in DbugParse was reading from beyond end of the control string dbug/dbug.c: Don't try to parse control strings that hasn't got any tokens or is zero size
-
unknown authored
client/mysqltest.c: Use the --tmpdir location to create temporary files
-
unknown authored
mysql-test/mysql-test-run.pl: Use the requested tmpdir in 'collect_mysqld_features', create it if it does not already exists
-
- 01 May, 2008 4 commits
-
-
unknown authored
into pcrews-mac-local.local:/Users/pcrews/usr/local/bin/data0/build_work/mysql-5.0-trigs
-
unknown authored
Bug#36028 - Test funcs_1.<engine>_trig_03e failing on Windows Bug#36029 - Test funcs_1.<engine>_trig_0407 failing on Windows Bug#36030 - Test funcs_1.<engine>_trig_08 failing on Windows Adding $MASTER_MYSOCK to init_win_path() When path names are short, master.sock ends up in MYSQL_TMP_DIR, but with longer path names, master.sock ends up in /tmp/<random_string>/ and these tests will fail due to path delimiter difference. New changeset to start with 5.0 -- Not all of these tests are present in 5.0, but want to keep mysqltest the same
-
unknown authored
The bug is a regression introduced by the patch for bug32798. The code in Item_func_group_concat::clear() relied on the 'distinct' variable to check if 'unique_filter' was initialized. That, however, is not always valid because Item_func_group_concat::setup() can do shortcuts in some cases w/o initializing 'unique_filter'. Fixed by checking the value of 'unique_filter' instead of 'distinct' before dereferencing. mysql-test/r/func_gconcat.result: Added test cases for bugs #35298 and #36024. mysql-test/t/func_gconcat.test: Added test cases for bugs #35298 and #36024. sql/item_sum.cc: Check if unique_filter != NULL before dereferencing it. Non-zero value of distinct does not always mean that unique_filter is initialized because Item_func_group_concat::setup() can do shortcuts is some cases
-
unknown authored
into magare.gmz:/home/kgeorge/mysql/work/merge-5.0-bugteam
-
- 30 Apr, 2008 1 commit
-
-
unknown authored
into ramayana.hindu.god:/home/tsmith/m/bk/build/50
-
- 28 Apr, 2008 5 commits
- 24 Apr, 2008 1 commit
-
-
unknown authored
When a zero length is provided to the my_decimal_length_to_precision function along with unsigned_flag set to false it returns a negative value. For queries that employs temporary tables may cause failed assertion or excessive memory consumption while temporary table creation. Now the my_decimal_length_to_precision and the my_decimal_precision_to_length functions take unsigned_flag into account only if the length/precision argument is non-zero. mysql-test/t/type_decimal.test: Added a test case for the bug#36023: Incorrect handling of zero length caused an assertion to fail. mysql-test/r/type_decimal.result: Added a test case for the bug#36023: Incorrect handling of zero length caused an assertion to fail. sql/my_decimal.h: Bug#36023: Incorrect handling of zero length caused an assertion to fail. Now the my_decimal_length_to_precision and the my_decimal_precision_to_length functions take unsigned_flag into account only if the length/precision argument is non-zero.
-
- 23 Apr, 2008 2 commits
- 22 Apr, 2008 3 commits
-
-
unknown authored
into host.loc:/home/uchum/work/5.0-bugteam
-
unknown authored
impossible WHERE/HAVING clause (subselect_single_select_engine::exec). Allocation and initialization of joined table list t1, t2... of subqueries like: NOT IN (SELECT ... FROM t1,t2,... WHERE 0) is optimized out, however server tries to traverse this list. mysql-test/r/subselect3.result: Added test case for bug#36005. mysql-test/t/subselect3.test: Added test case for bug#36005. sql/sql_select.cc: Fixed bug#36005. 1. JOIN::prepare initializes JOIN::table counter (actually a size of the JOIN::join_tab array) and sets it to a number of joined tables. 2. The make_join_statistics function (when called from JOIN::optimize) allocates and fills the JOIN::join_tab array. However, when optimizing subselect has impossible (definite false) WHERE or HAVING clause, optimizer skips call to make_join_statistics and leaves JOIN::join_tab == NULL. 3. subselect_single_select_engine::exec does traversal of the JOIN::join_tab array and the server dies because array is not allocated but array counter is greater than 0. The JOIN::optimize method has been modified to reset the JOIN::table counter to 0 in cause of impossible WHERE/HAVING clause.
-
unknown authored
Grouping or ordering of long values in not indexed BLOB/TEXT columns with GBK or BIG5 charsets crashes the server. MySQL server uses sorting (the filesort procedure) in the temporary table to evaluate the GROUP BY clause in case of lack of suitable index. That procedure takes into account only first @max_sort_length bytes (system variable, usually 1024) of TEXT/BLOB sorting key string. The my_strnxfrm_gbk and my_strnxfrm_big5 fill temporary keys with data of whole blob length instead of @max_sort_length bytes length. That buffer overrun has been fixed. mysql-test/r/ctype_gbk.result: Added test case for bug #35993. mysql-test/t/ctype_gbk.test: Added test case for bug #35993. strings/ctype-big5.c: Fixed bug #35993: memory corruption and crash with multibyte conversion. Buffer overrun has been fixed in the my_strnxfrm_big5 function. strings/ctype-gbk.c: Fixed bug #35993: memory corruption and crash with multibyte conversion. Buffer overrun has been fixed in the my_strnxfrm_gbk function.
-
- 21 Apr, 2008 1 commit
-
-
unknown authored
- Make convert_zerofill_number_to_string() take into account that the constant it is converting may evaluate to NULL. mysql-test/r/subselect.result: BUG#36139 "float, zerofill, crash with subquery" - Testcase mysql-test/t/subselect.test: BUG#36139 "float, zerofill, crash with subquery" - Testcase
-
- 18 Apr, 2008 1 commit
-
-
unknown authored
into trift2.:/MySQL/M50/push-5.0
-
- 17 Apr, 2008 1 commit
-
-
unknown authored
Include several "BUILD/compile-*" files in a source tarball ("make dist" target) which might be useful to community users who want to build from source. When merging this up, the "BUILD/compile-*" file list needs to be checked. BUILD/Makefile.am: Fix for Bug #34291 compile-amd64-debug-max-no-ndb missing Include several "BUILD/compile-*" files in a source tarball ("make dist" target) which might be useful to community users who want to build from source.
-
- 10 Apr, 2008 2 commits
-
-
unknown authored
sql/field.cc: Fix indentation of new line.
-
unknown authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-build mysql-test/r/type_blob.result: Auto merged mysql-test/t/type_blob.test: Auto merged sql/field.cc: Auto merged sql/item_create.cc: Auto merged sql/share/errmsg.txt: Auto merged sql/sql_yacc.yy: Auto merged sql/unireg.h: Auto merged
-
- 09 Apr, 2008 3 commits
-
-
unknown authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/bug15776-encore/my50-bug15776-encore sql/field.cc: Auto merged sql/item_create.cc: Auto merged sql/sql_yacc.yy: Auto merged sql/share/errmsg.txt: Auto merged sql/unireg.h: Auto merged mysql-test/r/type_blob.result: manual merge. mysql-test/t/type_blob.test: manual merge.
-
unknown authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-build mysql-test/r/type_blob.result: Auto merged mysql-test/t/type_blob.test: Auto merged sql/field.cc: Auto merged sql/unireg.h: Auto merged
-
unknown authored
Make maximum blob size to be 2**32-1, regardless of word size. Fix failure of timestamp with size of 2**31-1. The method of rounding up to the nearest even number would overflow. mysql-test/r/type_blob.result: 2**32-1 is not a special case for timestamp. Test 2**32-1 and 2**64 as the reliable test points for both 32- and 64-bit machines. I'd like to test 2**32, but that would make tests that vary between architectures. I'd like to generalize the tests by pulling the max blob size from the server, and then "eval"ing N-1, N, and N+1 instead of all these literal numbers, but I have not found a way to get UINT_MAX. mysql-test/t/type_blob.test: 2**32-1 is not a special case for timestamp. Test 2**32-1 and 2**64 as the reliable test points for both 32- and 64-bit machines. I'd like to test 2**32, but that would make tests that vary between architectures. I'd like to generalize the tests by pulling the max blob size from the server, and then "eval"ing N-1, N, and N+1 instead of all these literal numbers, but I have not found a way to get UINT_MAX. sql/field.cc: Fix a bug where the round-to-even code for TIMESTAMP fields failed where the size would overflow the size to zero and then fail. Also, since we silently truncate the size of TIMESTAMP fields, set the maximum size we report is allowable to be the largest parsable number. sql/unireg.h: Make BLOB size the maximum that the packed value in field_blob::get_length() allows.
-
- 04 Apr, 2008 1 commit
-
-
unknown authored
into five.local.lan:/work/trees/mysql-5.0-build-src-clean
-