- 14 Mar, 2006 3 commits
-
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-5.0
-
evgen@sunlight.local authored
Afterfix for bug#17366: Unchecked Item_int results in server crash
-
evgen@sunlight.local authored
into sunlight.local:/work_local/17336-bug-5.0-mysql
-
- 13 Mar, 2006 11 commits
-
-
evgen@sunlight.local authored
When there is conjunction of conds, the substitute_for_best_equal_field() will call the eliminate_item_equal() function in loop to build final expression. But if eliminate_item_equal() finds that some cond will always evaluate to 0, then that cond will be substituted by Item_int with value == 0. In this case on the next iteration eliminate_item_equal() will get that Item_int and treat it as Item_cond. This is leads to memory corruption and server crash on cleanup phase. To the eliminate_item_equal() function was added DBUG_ASSERT for checking that all items treaten as Item_cond are really Item_cond. The substitute_for_best_equal_field() now checks that if eliminate_item_equal() returns Item_int and it's value is 0 then this value is returned as the result of whole conjunction.
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-5.0
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-4.1
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/50-work
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-4.1
-
jonas@perch.ndb.mysql.com authored
ndb crash if trigger record get to big, fix incorrect max size of trigger record
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-5.0
-
jonas@perch.ndb.mysql.com authored
ndb crash if trigger record get to big, fix incorrect max size of trigger record
-
msvensson@shellback.(none) authored
into shellback.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@shellback.(none) authored
-
msvensson@shellback.(none) authored
-
- 11 Mar, 2006 2 commits
-
-
aelkin@mysql.com authored
into mysql.com:/usr_rh9/home/elkin.rh9/MySQL/FIXES/5.0.20-bug15101-sysdate
-
kent@mysql.com authored
into mysql.com:/Users/kent/mysql/bk/mysql-5.0-new
-
- 10 Mar, 2006 18 commits
-
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-4.1-bug14980
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug14980
-
joerg@mysql.com authored
-
anozdrin@mysql.com authored
Now DEFINER-clause in stored routines is expected to appear in 5.0.20 release, not in 5.0.19. as it was supposed before.
-
joerg@mysql.com authored
into mysql.com:/M50/merge-5.0
-
joerg@mysql.com authored
-
joerg@mysql.com authored
Fixes bug#15861
-
aelkin@mysql.com authored
into mysql.com:/usr_rh9/home/elkin.rh9/MySQL/FIXES/5.0.20-bug15101-sysdate
-
aelkin@mysql.com authored
After the ChangeSet 1.1892.20.1 2005/08/24 (Bug #12562) SYSDATE() is not an alias of NOW() and is unsafe for replication. `SYSDATE()' backward compatible aliasing clashes with the idea #12562 fix. To make it safe-replicatable we have to either use RBR or to restore the pre-5.0 style. --sysdate-is-now command line flag was introduced to provide backward compatibility.
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug14980
-
ingo@mysql.com authored
For "count(*) while index_column = value" an index read is done. It consists of an index scan and retrieval of each key. For efficiency reasons the index scan stores the key in the special buffer 'lastkey2' once only. At the first iteration it notes this fact with the flag HA_STATE_RNEXT_SAME in 'info->update'. For efficiency reasons, the key retrieval for blobs does not allocate a new buffer, but uses 'lastkey2'... Now I clear the HA_STATE_RNEXT_SAME flag whenever the buffer has been polluted. In this case, the index scan copies the key value again (and sets the flag again).
-
anozdrin@mysql.com authored
w/o definer if --skip-grant-tables specified. The previous patch does not allow to specify empty host name in DEFINER-clause explicitly.
-
joerg@mysql.com authored
-
evgen@moonbone.local authored
produce wrong data By default Item_sp_func::val_str() returns string from it's result_field internal buffer. When grouping is present Item_copy_string is used to store SP function result, but it doesn't additionally buffer the result. When the next record is read, internal buffer is overwritten, due to this Item_copy_string::val_str() will have wrong data. Thus producing weird query result. The Item_func_sp::val_str() now makes a copy of returned value to prevent occasional corruption.
-
joerg@mysql.com authored
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
brian@zim.(none) authored
into zim.(none):/home/brian/mysql/mysql-5.0
-
brian@zim.(none) authored
This patch does 1) fix my build breakage 2) Complete the removal of all symbols which could clash with another parser.
-
- 09 Mar, 2006 6 commits
-
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
paul@snake-hub.snake.net authored
Fix typos.
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
brian@zim.(none) authored
Makes you wonder what I am up to, doesn't?
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-