- 11 Aug, 2006 2 commits
-
-
svoj@may.pils.ru authored
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG7391/mysql-5.0
-
- 10 Aug, 2006 3 commits
-
-
cmiller@zippy.cornsilk.net authored
-
cmiller@zippy.cornsilk.net authored
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0
-
- 09 Aug, 2006 3 commits
-
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG20060/mysql-5.0
-
svoj@may.pils.ru authored
Problem described in this bug report affects MyISAM tables only. Running mysqld --flush instructs mysqld to sync all changes to disk after each SQL statement. It worked well for INSERT and DELETE statements, but it did sync for UPDATE only in case if there was index change (change of colum that has an index). If no updated column has an index, data wasn't synced to disk. This fix makes UPDATE statement to sync data to disk even if there is no index change (that is only data change) and mysqld is run with --flush option.
-
evgen@sunlight.local authored
After merge fix
-
- 08 Aug, 2006 3 commits
-
-
evgen@sunlight.local authored
into sunlight.local:/local_work/leak_fix
-
evgen@sunlight.local authored
into sunlight.local:/local_work/leak_fix
-
evgen@sunlight.local authored
Correct memory leak fix
-
- 07 Aug, 2006 1 commit
-
-
evgen@sunlight.local authored
Memory leak fix
-
- 06 Aug, 2006 3 commits
-
-
evgen@sunlight.local authored
into sunlight.local:/local_work/leak_fix
-
evgen@sunlight.local authored
into sunlight.local:/local_work/leak_fix
-
evgen@sunlight.local authored
Memory leak fix
-
- 03 Aug, 2006 18 commits
-
-
kostja@bodhi.local authored
-
kostja@bodhi.local authored
-
msvensson@neptunus.(none) authored
-
msvensson@neptunus.(none) authored
now takes mbmaxlen into account when calculating max_length of new field.
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG7391/mysql-4.1
-
msvensson@neptunus.(none) authored
- Backport patch from 5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
-
msvensson@neptunus.(none) authored
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-4.1
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG7391/mysql-4.1
-
svoj@may.pils.ru authored
privileges This problem is 4.1 specific. It doesn't affect 4.0 and was fixed in 5.x before. Having any mysql user who is allowed to issue multi table update statement and any column/table grants, allows this user to update any table on a server (mysql grant tables are not exception). check_grant() accepts number of tables (in table list) to be checked in 5-th param. While checking grants for multi table update, number of tables must be 1. It must never be 0 (actually we have DBUG_ASSERT(number > 0) in 5.x in grant_check() function).
-
msvensson@neptunus.(none) authored
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
-
jimw@rama.(none) authored
into rama.(none):/home/jimw/my/mysql-5.0-16502
-
jimw@rama.(none) authored
into rama.(none):/home/jimw/my/mysql-5.0-16502
-
jimw@rama.(none) authored
into rama.(none):/home/jimw/my/mysql-5.0-16502
-
- 02 Aug, 2006 7 commits
-
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/m41-maint--07OBQ
-
kostja@bodhi.local authored
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge
-
cmiller@zippy.cornsilk.net authored
set. (Ramil's patch, recreated.)
-
kostja@bodhi.local authored
-
iggy@rolltop.ignatz42.dyndns.org authored
into rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-4.1-maint_bug20721
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-