- 15 Aug, 2007 3 commits
-
-
mhansson@dl145s.mysql.com authored
into dl145s.mysql.com:/data0/mhansson/my51-bug28570
-
mhansson/martin@linux-st28.site authored
into linux-st28.site:/home/martin/mysql/src/bug28570/my51-bug28570
-
mhansson/martin@linux-st28.site authored
ORDER BY is used The range analysis module did not correctly signal to the handler that a range represents a ref (EQ_RANGE flag). This causes non-range queries like SELECT ... FROM ... WHERE keypart_1=const, ..., keypart_n=const ORDER BY ... FOR UPDATE to wait for a lock unneccesarily if another running transaction uses SELECT ... FOR UPDATE on the same table. Fixed by setting EQ_RANGE for all range accesses that represent an equality predicate.
-
- 14 Aug, 2007 3 commits
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.1-opt
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.1-opt
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
- 13 Aug, 2007 5 commits
-
-
istruewing@synthia.local authored
into synthia.local:/home/mydev/mysql-5.1-axmrg
-
istruewing@synthia.local authored
into synthia.local:/home/mydev/mysql-5.1-axmrg
-
istruewing@synthia.local authored
into synthia.local:/home/mydev/mysql-5.0-axmrg
-
istruewing@synthia.local authored
into synthia.local:/home/mydev/mysql-5.0-axmrg
-
istruewing@synthia.local authored
into synthia.local:/home/mydev/mysql-4.1-axmrg
-
- 10 Aug, 2007 4 commits
-
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.1-opt
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.1-opt
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.0-opt
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/home/uchum/work/bk/5.1-opt
-
- 08 Aug, 2007 5 commits
-
-
kostja@bodhi.(none) authored
-
kostja@bodhi.(none) authored
during "CREATE ... LIKE ..." Only affects engine writers. No change in server behaviour.
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.1-runtime
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
- 06 Aug, 2007 19 commits
-
-
kostja@bodhi.(none) authored
-
-
kostja@bodhi.(none) authored
-
kostja@bodhi.(none) authored
-
kostja@bodhi.(none) authored
-
gkodinov/kgeorge@magare.gmz authored
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B29536-5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/work/B29536-5.1-opt
-
gkodinov/kgeorge@magare.gmz authored
MySQL replicates the time zone only when operations that involve it are performed. This is controlled by a flag. But this flag is set only on successful operation. The flag must be set also when there is an error that involves a timezone (so the master would replicate the error to the slaves). Fixed by moving the setting of the flag before the operation (so it apples to errors as well).
-
kostja@bodhi.(none) authored
into bodhi.(none):/opt/local/work/mysql-5.0-runtime
-
kostja@bodhi.(none) authored
VIEW". mysql_list_fields() C API function would incorrectly set MYSQL_FIELD::decimals member for some view columns. The problem was in an incomplete implementation of Item_ident_for_show::make_field(), which is responsible for view columns metadata.
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.1-opt
-
igor@olga.mysql.com authored
a problem for BIT type values different from the one reported for the bug.
-
igor@olga.mysql.com authored
-
kent@kent-amd64.(none) authored
into mysql.com:/home/kent/bk/cmake-tls/mysql-5.1-build-new
-
kent@mysql.com/kent-amd64.(none) authored
Corrected install path
-
kent@mysql.com/kent-amd64.(none) authored
Copy embedded .pdb and static debug lib
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.1-opt-bug30219
-
igor@olga.mysql.com authored
-
- 05 Aug, 2007 1 commit
-
-
kent@kent-amd64.(none) authored
into mysql.com:/home/kent/bk/cmake-tls/mysql-5.1-build-new
-