- 06 Mar, 2007 1 commit
-
-
unknown authored
into chilla.local:/home/mydev/mysql-5.0-bug26464 mysql-test/t/merge.test: Auto merged mysql-test/r/merge.result: Bug#26464 - insert delayed + update + merge = corruption Manual merge from 4.1 sql/ha_myisammrg.h: Bug#26464 - insert delayed + update + merge = corruption Manual merge from 4.1
-
- 05 Mar, 2007 1 commit
-
-
unknown authored
Using INSERT DELAYED on MERGE tables could lead to table corruptions. The manual lists a couple of storage engines, which can be used with INSERT DELAYED. MERGE is not in this list. The attempt to try it anyway has not been rejected yet. This bug was not detected earlier as it can work under special circumstances. Most notable is low concurrency. To be safe, this patch rejects any attempt to use INSERT DELAYED on MERGE tables. mysql-test/r/merge.result: Bug#26464 - insert delayed + update + merge = corruption Added test result. mysql-test/t/merge.test: Bug#26464 - insert delayed + update + merge = corruption Added test. sql/ha_myisammrg.h: Bug#26464 - insert delayed + update + merge = corruption Removed HA_CAN_INSERT_DELAYED flag from table_flags(). The insert delayed thread upgrades the lock from the first entry in MYSQL_LOCK::locks only. Hence it is incapable to handle MERGE tables, which have as many entries in this array as they have MyISAM sub-tables.
-
- 28 Feb, 2007 1 commit
-
-
unknown authored
INSERT DELAYED inserts garbage for BIT columns. When delayed thread clones TABLE object, it didn't adjusted bit_ptr to newly created record (though it correctly adjusts ptr and null_ptr). This is fixed by correctly adjusting bit_ptr when performing a clone. With this fix BIT values are stored correctly by INSERT DELAYED. mysql-test/r/delayed.result: A test case for BUG#26238. mysql-test/t/delayed.test: A test case for BUG#26238. sql/field.h: Added move_field() to Field_bit class. When moving a field, adjust bit_ptr also, which is specific to Field_bit class.
-
- 20 Feb, 2007 3 commits
- 16 Feb, 2007 1 commit
-
-
unknown authored
into chilla.local:/home/mydev/mysql-5.0-axmrg
-
- 14 Feb, 2007 3 commits
-
-
unknown authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint sql/mysql_priv.h: Auto merged
-
unknown authored
into chilla.local:/home/mydev/mysql-5.0-axmrg sql/item.cc: Auto merged sql/item_cmpfunc.cc: Auto merged sql/item_cmpfunc.h: Auto merged sql/sql_select.cc: Auto merged
-
unknown authored
into chilla.local:/home/mydev/mysql-5.0-axmrg mysys/my_pthread.c: SCCS merged
-
- 13 Feb, 2007 9 commits
-
-
unknown authored
-
unknown authored
into bk-internal.mysql.com:/data0/bk/mysql-5.0-opt BitKeeper/etc/gone: auto-union mysys/my_getopt.c: Auto merged sql/field.h: Auto merged sql/item.cc: Auto merged sql/item_cmpfunc.cc: Auto merged sql/item_cmpfunc.h: Auto merged sql/mysql_priv.h: Auto merged sql/sql_prepare.cc: Auto merged sql/sql_select.cc: Auto merged sql/table.cc: Auto merged mysql-test/r/select.result: Manual merge mysql-test/t/select.test: Manual merge
-
unknown authored
Showstopper and regression against 5.0.24. Previously, we ignored seek() errors (see Bug#22828) and let seek()s against pipes fail. Now, since we check that a seek didn't fail, and return without reading, this bug popped up. This restores the behavior for file-ish objects that could never be seek()ed. mysys/mf_iocache.c: If we detect early that the file is not tell()able, then we should assume that it's also not seek()able and therefore we should never set the (poorly named) "seek_not_done" flag so that we don't immedi- ately try to seek() when reading later. The problem was that tell() was returning -1, so when we read later, we needlessly tried to seek to position (unsigned long) -1 . Also, if we think we're supposed to seek to a position in a file and the file is un-tell()able, then abort.
-
unknown authored
into bk-internal.mysql.com:/data0/bk/mysql-4.1-opt
-
unknown authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint sql/item.cc: Auto merged sql/item_cmpfunc.cc: Auto merged sql/item_cmpfunc.h: Auto merged sql/sql_select.cc: Auto merged
-
unknown authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint sql/mysql_priv.h: Auto merged
-
unknown authored
into pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint BitKeeper/etc/ignore: auto-union
-
unknown authored
into pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint BitKeeper/etc/gone: auto-union mysys/my_getopt.c: Auto merged sql/sql_prepare.cc: Auto merged sql/table.cc: Auto merged
-
unknown authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26209 sql/sql_select.cc: Auto merged
-
- 12 Feb, 2007 17 commits
-
-
unknown authored
into mysql.com:/home/hf/work/25492/my50-25492 sql/item.cc: Auto merged
-
unknown authored
into mysql.com:/home/hf/work/25492/my50-25492
-
unknown authored
into mysql.com:/home/hf/work/25492/my41-25492
-
unknown authored
into mysql.com:/home/hf/work/25492/my50-25492 libmysqld/lib_sql.cc: merging
-
unknown authored
libmysqld/lib_sql.cc: code modified to prevent freeing of memory that wasn't malloc-ed. Now we check if MYSQL_STMT::result was used.
-
unknown authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
unknown authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
unknown authored
-
unknown authored
Common symbols with and without initialization cause the apple linker to exclude then from the list of global symbols.
-
unknown authored
into mysql.com:/home/tnurnberg/24660/50-24660 sql/table.cc: Auto merged sql/unireg.cc: Auto merged
-
unknown authored
into mysql.com:/home/tnurnberg/24660/41-24660 sql/table.cc: Auto merged
-
unknown authored
into mysql.com:/home/tnurnberg/24660/50-24660 mysql-test/r/type_enum.result: Auto merged sql/table.cc: Auto merged sql/unireg.cc: Auto merged
-
unknown authored
ENUMs weren't allowed to have character 0xff, a perfectly good character in some locales. This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from being used. Now if 0xff makes an appearance, we find a character not used in the enum and use that as a separator. If no such character exists, we throw an error. Any solution would have broken some sort of existing behaviour. This solution should serve both fractions (those with 0xff and those with ',' in their enums), but WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/ That is, mysqldump with their current server, and restore when upgrading to one with this patch. mysql-test/r/type_enum.result: Bug#24660: "enum" field type definition problem Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable char in some locales), or ',', or both. mysql-test/t/type_enum.test: Bug#24660: "enum" field type definition problem Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable char in some locales), or ',', or both. sql/table.cc: Bug#24660: "enum" field type definition problem Revert fix for Bug#20922. sql/unireg.cc: Bug#24660: "enum" field type definition problem Use a field-separator for ENUM-values that is not part of those values. If impossible, throw error.
-
unknown authored
The crash happens because second filling of the same I_S table happens in case of subselect with order by. table->sort.io_cache previously allocated in create_sort_index() is deleted during second filling (function get_schema_tables_result). There are two places where I_S table can be filled: JOIN::exec and create_sort_index(). To fix the bug we should check if the table was already filled in one of these places and skip processing of the table in second. mysql-test/r/information_schema.result: test case mysql-test/t/information_schema.test: test case sql/mysql_priv.h: added new parameter 'executed_place' to function get_schema_tables_result() sql/sql_select.cc: added new parameter 'executed_place' to function get_schema_tables_result() sql/sql_show.cc: added more accurate check for cases when we need to refresh I_S table sql/table.cc: added more accurate check for cases when we need to refresh I_S table sql/table.h: added more accurate check for cases when we need to refresh I_S table
-
unknown authored
Some fields (GEOMETRY first of all) can't be handled properly in this case at all. So we return an error in this case mysql-test/r/default.result: result fixed mysql-test/r/gis.result: result fixed mysql-test/t/default.test: VIEW test added mysql-test/t/gis.test: testcase added sql/item.cc: set_defaults() changed with the 'reset()'
-
unknown authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26159
-
unknown authored
The function make_unireg_sortorder ignored the fact that any view field is represented by a 'ref' object. This could lead to wrong results for the queries containing both GROUP BY and ORDER BY clauses. mysql-test/r/view.result: Added a test case for bug #26209. mysql-test/t/view.test: Added a test case for bug #26209.
-
- 11 Feb, 2007 3 commits
-
-
unknown authored
Post fix for bug#12122. information_schema.result: Corrected test case after fixing bug#12122. sql/sql_view.cc: Post fix for bug#12122. mysql-test/r/information_schema.result: Corrected test case after fixing bug#12122.
-
unknown authored
into moonbone.local:/mnt/gentoo64/work/12122-bug-5.0-opt-mysql
-
unknown authored
A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset caused a crash when a query with DISTINCT was executed by a loose scan for an InnoDB table that had been emptied. mysql-test/r/innodb_mysql.result: Added a test case for bug #26159. mysql-test/t/innodb_mysql.test: Added a test case for bug #26159. sql/opt_range.cc: Fixed bug #26159. A wrong order of statements in QUICK_GROUP_MIN_MAX_SELECT::reset caused a crash when a query with DISTINCT was executed by a loose scan for an InnoDB table that had been emptied. For an empty table quick_prefix_select->reset() was not called at all and thus some important initialization steps were missing.
-
- 09 Feb, 2007 1 commit
-
-
unknown authored
present. A view created with CREATE VIEW ... ORDER BY ... cannot be resolved with the MERGE algorithm, even when no other part of the CREATE VIEW statement would require the view to be resolved using the TEMPTABLE algorithm. The check for presence of the ORDER BY clause in the underlying select is removed from the st_lex::can_be_merged() function. The ORDER BY list of the underlying select is appended to the ORDER BY list mysql-test/t/view.test: Added a test case for bug#12122: Views with ORDER BY can't be resolved using MERGE algorithm. mysql-test/r/view.result: Added a test case for bug#12122: Views with ORDER BY can't be resolved using MERGE algorithm. sql/sql_lex.cc: Bug#12122: Views with ORDER BY can't be resolved using MERGE algorithm. The st_lex::can_be_merged() function now allows views with the ORDER BY clause to be resolved using MERGE algorithm. The ORDER BY list of the view is appended to the ORDER BY list of the embedding select.
-