- 15 Mar, 2007 1 commit
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug25289
-
- 14 Mar, 2007 1 commit
-
-
istruewing@chilla.local authored
my_seek: Assertion `fd != -1' failed" In difficult optimize/repair situations the server could crash. Under some circumstances the server retries an optimize/repair with more elaborate options. But it did not check if the first attempt failed so badly that a second one must not be tried. This could happen when a new data file has been created but it was not possible to open it. In this case the repair leaves behind a table with closed data file. This must not be used for another repair attempt. We do now detect the closed data file and do not try another repair attempt in this situation. No test case. The required table corruption can not be repeated easily. There is a test program attached to bug 25433.
-
- 06 Mar, 2007 1 commit
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug26464
-
- 05 Mar, 2007 1 commit
-
-
istruewing@chilla.local 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.
-
- 28 Feb, 2007 1 commit
-
-
svoj@mysql.com/june.mysql.com 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.
-
- 20 Feb, 2007 3 commits
-
-
istruewing@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-5.0-engines
-
-
istruewing@chilla.local authored
-
- 16 Feb, 2007 1 commit
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-axmrg
-
- 14 Feb, 2007 3 commits
-
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint
-
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
-
- 13 Feb, 2007 9 commits
-
-
igor@olga.mysql.com authored
-
ibabaev@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-5.0-opt
-
cmiller@zippy.cornsilk.net 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.
-
ibabaev@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-4.1-opt
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint
-
msvensson@pilot.mysql.com authored
into pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26209
-
- 12 Feb, 2007 17 commits
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/25492/my50-25492
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/25492/my50-25492
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/25492/my41-25492
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/25492/my50-25492
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
gluh@mysql.com/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/5.0-opt
-
gluh@mysql.com/eagle.(none) authored
-
gkodinov/kgeorge@macbook.gmz authored
Common symbols with and without initialization cause the apple linker to exclude then from the list of global symbols.
-
tnurnberg@mysql.com/sin.azundris.com authored
into mysql.com:/home/tnurnberg/24660/50-24660
-
tnurnberg@mysql.com/sin.azundris.com authored
into mysql.com:/home/tnurnberg/24660/41-24660
-
tnurnberg@mysql.com/sin.azundris.com authored
into mysql.com:/home/tnurnberg/24660/50-24660
-
tnurnberg@mysql.com/sin.azundris.com 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.
-
gluh@mysql.com/eagle.(none) 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.
-
holyfoot/hf@mysql.com/hfmain.(none) 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
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26159
-
igor@olga.mysql.com 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.
-
- 11 Feb, 2007 2 commits
-
-
evgen@moonbone.local authored
Post fix for bug#12122. information_schema.result: Corrected test case after fixing bug#12122.
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/12122-bug-5.0-opt-mysql
-