- 09 Mar, 2007 5 commits
-
-
bk://localhost:5556xxx/istruewing@blade08.mysql.com authored
into blade08.mysql.com:/data0/istruewing/autopush/mysql-5.1-bug25673
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.1-bug25673
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug25673
-
istruewing@chilla.local authored
Fixed a compiler warning, deteced by pushbuild only.
-
xxx/istruewing@blade08.mysql.com authored
into blade08.mysql.com:/data0/istruewing/autopush/mysql-5.1-bug25673
-
- 08 Mar, 2007 7 commits
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.1-bug25673
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug25673
-
istruewing@chilla.local authored
After backport fix. Added forgotten DBUG_RETURNs, which was detected in 5.1 only.
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.1-bug25673
-
istruewing@chilla.local authored
After merge fix
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug25673
-
istruewing@chilla.local authored
incorrect key file for table In certain cases it could happen that deleting a row could corrupt an RTREE index. According to Guttman's algorithm, page underflow is handled by storing the page in a list for later re-insertion. The keys from the stored pages have to be inserted into the remaining pages of the same level of the tree. Hence the level number is stored in the re-insertion list together with the page. In the MySQL RTree implementation the level counts from zero at the root page, increasing numbers for levels down the tree. If during re-insertion of the keys the tree height grows, all level numbers become invalid. The remaining keys will be inserted at the wrong level. The fix is to increment the level numbers stored in the reinsert list after a split of the root block during reinsertion.
-
- 06 Mar, 2007 2 commits
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.1-bug26464
-
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.
-
- 02 Mar, 2007 2 commits
-
-
svoj@june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG26238/mysql-5.1-engines
-
svoj@june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG26238/mysql-5.1-engines
-
- 28 Feb, 2007 5 commits
-
-
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.
-
gluh@mysql.com/eagle.(none) authored
-
svoj@mysql.com/june.mysql.com authored
Extending varchar column length with ALTER TABLE may result in unusable memory table. The problem is that we use fast ALTER TABLE in this case, which is not supported by now. This is fixed by refusing fast ALTER TABLE when extending varchar column. In other words force copy of a table during ALTER TABLE. Affects MEMORY tables in 5.1 only.
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@mysql.com/eagle.(none) authored
-
- 27 Feb, 2007 8 commits
-
-
sergefp@pylon.mylan authored
into mysql.com:/home/psergey/mysql-5.1-bug26117
-
sergefp@mysql.com authored
Before the fix: ha_partition objects had ha_partition::m_part_info==NULL and that caused crash After: - The new ha_partition::clone() function makes the clones use parent's m_part_info value. - The parent ha_partition object remains responsible for deallocation of m_part_info.
-
monty@mysql.com/narttu.mysql.fi authored
-
monty@mysql.com/narttu.mysql.fi authored
-
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@mysql.com/eagle.(none) authored
-
gluh@mysql.com/eagle.(none) authored
-
- 26 Feb, 2007 9 commits
-
-
gluh@mysql.com/eagle.(none) authored
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gluh@mysql.com/eagle.(none) authored
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
knielsen@ymer.(none) authored
into ymer.(none):/tmp/mysql-5.1
-
knielsen@ymer.(none) authored
-
evgen@sunlight.local authored
Post fix for bug#23800.
-
- 25 Feb, 2007 1 commit
-
-
evgen@sunlight.local authored
Post fix for bug#23800. Copy the table name of an Item_outer_ref to the conventional memory.
-